Design Question - how do you break the dependency between classes using an interface?
Posted
by Seth Spearman
on Stack Overflow
See other posts from Stack Overflow
or by Seth Spearman
Published on 2010-06-02T01:27:49Z
Indexed on
2010/06/02
1:33 UTC
Read the original article
Hit count: 331
Hello, I apologize in advance but this will be a long question.
I'm stuck. I am trying to learn unit testing, C#, and design patterns - all at once. (Maybe that's my problem.) As such I am reading the Art of Unit Testing (Osherove), and Clean Code (Martin), and Head First Design Patterns (O'Reilly).
I am just now beginning to understand delegates and events (which you would see if you were to troll my SO questions of recent). I still don't quite get lambdas.
To contextualize all of this I have given myself a learning project I am calling goAlarms. I have an Alarm class with members you'd expect (NextAlarmTime, Name, AlarmGroup, Event Trigger etc.)
I wanted the "Timer" of the alarm to be extensible so I created an IAlarmScheduler interface as follows...
public interface AlarmScheduler
{
Dictionary<string,Alarm> AlarmList { get; }
void Startup();
void Shutdown();
void AddTrigger(string triggerName, string groupName, Alarm alarm);
void RemoveTrigger(string triggerName);
void PauseTrigger(string triggerName);
void ResumeTrigger(string triggerName);
void PauseTriggerGroup(string groupName);
void ResumeTriggerGroup(string groupName);
void SetSnoozeTrigger(string triggerName, int duration);
void SetNextOccurrence (string triggerName, DateTime nextOccurrence);
}
This IAlarmScheduler interface define a component that will RAISE an alarm (Trigger) which will bubble up to my Alarm class and raise the Trigger Event of the alarm itself. It is essentially the "Timer" component.
I have found that the Quartz.net component is perfectly suited for this so I have created a QuartzAlarmScheduler class which implements IAlarmScheduler.
All that is fine. My problem is that the Alarm class is abstract and I want to create a lot of different KINDS of alarm. For example, I already have a Heartbeat alarm (triggered every (int) interval of minutes), AppointmentAlarm (triggered on set date and time), Daily Alarm (triggered every day at X) and perhaps others.
And Quartz.NET is perfectly suited to handle this.
My problem is a design problem. I want to be able to instantiate an alarm of any kind without my Alarm class (or any derived classes) knowing anything about Quartz. The problem is that Quartz has awesome factories that return just the right setup for the Triggers that will be needed by my Alarm classes. So, for example, I can get a Quartz trigger by using TriggerUtils.MakeMinutelyTrigger to create a trigger for the heartbeat alarm described above. Or TriggerUtils.MakeDailyTrigger for the daily alarm.
I guess I could sum it up this way. Indirectly or directly I want my alarm classes to be able to consume the TriggerUtils.Make* classes without knowing anything about them. I know that is a contradiction, but that is why I am asking the question.
I thought about putting a delegate field into the alarm which would be assigned one of these Make method but by doing that I am creating a hard dependency between alarm and Quartz which I want to avoid for both unit testing purposes and design purposes. I thought of using a switch for the type in QuartzAlarmScheduler per here but I know it is bad design and I am trying to learn good design.
If I may editorialize a bit. I've decided that coding (predefined) classes is easy. Design is HARD...in fact, really hard and I am really fighting feeling stupid right now. I guess I want to know if you really smart people took a while to really understand and master this stuff or should I feel stupid (as I do) because I haven't grasped it better in the couple of weeks/months I have been studying.
You guys are awesome and thanks in advance for your answers.
Seth
© Stack Overflow or respective owner