Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Anybody can ask a question
Anybody can answer
The best answers are voted up and rise to the top
I want to create a little todo app, with a “pedagogic focus” on clean software design.
I spent some time reading about design patterns lately and I am trying to wrap my mind about which of them I could and should use.
Features I want my “todo items” to provide:
- has a due date
- has a due date and due time
- is “timeless”
- simple (you fulfill the task and cross it from the list)
- turns (you have to perform 3 sets of pullups to fulfill the task)
- time (you need to gather 30 minutes in total of piano practicing to fulfill the task)
Continuity (with given frequency, e.g. 3 days)
- once (once done it’s gone)
- multiple (task is repeated n times with given frequency)
- continuous (task is repeated indefinitely with given frequency)
I then tried to find design concepts to implement these features; here are my thoughts:
Feature families 1-3 suggest three independent “properties” of a todo item, which could be three distinct strategy interfaces like
Yet, considering timing strategies, all three available concrete strategies, i.e.
TimelessTimingStrategy, would use different sets of parameters (time, datetime or no time fields) which can not be put into practicve using the standard strategy pattern.
I could also introduce a
TimingParameterclass which is used by
TimingStrategyto address this problem, but then again…: Is this too much in this case?
For my understanding, a decorator pattern is not suitable here because I want to pick one behavior for the todo’s “guts” and not “augment” behavior on the todo’s “skin”. Also using decorator would allow me to pick more than one timing behavior which should not be possible.
The completion feature could actually be provided by using the strategy pattern, because one-interface-for-all is thinkable: The
SimpleCompletionStrategycould be seen as a special case of
CumulativeTurnsCompletionStrategywhere the number of turns is 1.
The continuity property could be implemented by using the strategy pattern
The reminder feature could be part of the basic “todo” class, but what does this mean when picking the
TimelessTimingStrategy? Such a todo can’t have a reminder! If the todo class checks whether reminding is allowed this breaks separation of concenrns. Should the
TimingStrategyinterface provide a
If one of the feature families (or a new one) would allow for pick-n-out-of-m-options, this would demand a decorator pattern? Or an
Am I trying to force in patterns just because I read about them recently?
Not using composition/patterns but inheritance would lead to class explosion
Maybe one of the feature families could be implemented via inheritance (e.g.
Todobase class with an
isDue()method and strategies for completion and continuity and then child classes according to Timing, thus
TimelessTodo, for instance.
I’m very open to your suggestions and comments. Your propositions for an architecture and comments on specific bullets in my lists are both very welcome!