How to determine whether (and how) my design should use inheritance, composition, decoration and/or strategy

Question

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:

1. Timing

   • has a due date
   • has a due date and due time
   • is "timeless"

2. Completion

   • simple (you fulfill the task and cross it from the list)
   • cumulative
     • 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)

3. 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)

4. Optional reminder

I then tried to find design concepts to implement these features; here are my thoughts:

1. Feature families 1-3 suggest three independent "properties" of a todo item, which could be three distinct strategy interfaces like TimingStrategy, CompletionStrategy and ContinuityStrategy.

2. Yet, considering timing strategies, all three available concrete strategies, i.e. DueDateTimingStrategy, DueDatetimeTimingStrategy and 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.

3. I could also introduce a TimingParameter class which is used by TimingStrategy to address this problem, but then again...: Is this too much in this case?

4. 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.

5. The completion feature could actually be provided by using the strategy pattern, because one-interface-for-all is thinkable: The SimpleCompletionStrategy could be seen as a special case of CumulativeTurnsCompletionStrategy where the number of turns is 1.

6. The continuity property could be implemented by using the strategy pattern

7. 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 TimingStrategy interface provide a canReminderBeSet() method?

8. 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 OptionManager class?

9. Am I trying to force in patterns just because I read about them recently?

10. Not using composition/patterns but inheritance would lead to class explosion DueDateSimpleOnceTodo, TimelessCumulativeTurnsContinuousTodo, ...

11. Maybe one of the feature families could be implemented via inheritance (e.g. Todo base class with an isDue() method and strategies for completion and continuity and then child classes according to Timing, thus DueDateTodo, DueDatetimeTodo and 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!

Answer 1

The first thing I would ask myself here is: is it really necessary to use any kind of inheritance at all?

So why not start by defining four types for Timing, Completion, Continuity and Reminder, then your ToDoItem is simply a class with four attributes of these types, plus a fifth string attribute "description". The four types may be implemented by simple classes and enums, but I don't see a compelling reason to start with inheritance here. For example, the Timing class could consist of

• a date-time attribute

• an attribute of an enum-type with 3 values (like Timing_date, Timing_datetime, Timing_none), which holds the information how to interpret the date-time attribute.

In reality, I would not even start with the five attributes. I would start with the most simple design for a TodoItem class I can think of - a class with just a "description" attribute. Then I would implement it - in code! No inheritance, no composition, no strategy, no decoration, no patterns. Next step would be to write a program around it to display, add, or delete these Todo items, and also wite some tests for it.

When adding more features to the program, one by one, the TodoItem class can be extended as required, as well as the tests. Whenever some part of the program becomes too unstructured, refactor, to avoid duplication, to keep the system comprehensible, maintainable and testable.

Maybe later, during this processs, when your program grows, Timing may require three different subclasses, and it will evolve into a strategy object (see Fowler's refactoring catalog, "Replace Type Code with Subclasses"). But do yourself a favor and don't start with that "just in case". Better ask yourself regularly "do I really need a pattern for this, or can keep things simpler by using no pattern"?

Answer 2

I have grave misgivings about your approach.

Software patterns are not a "recipe book."

The purpose of software patterns is not to stitch together an application with them, like sewing a quilt. First of all, that won't work. Because Software Patterns are not a comprehensive catalog, there are large gaps in what you can do with them, so (if, in fact, you wish to call yourself a software engineer someday), you must still write code that solves novel problems.

Software patterns are well-known solutions to specific problems in software development. They're not a development strategy. Instead of asking "What software patterns should I use," you should be asking "Is the specific architectural/algorithmic problem I am looking at already solved by a well-known software pattern?

In other words, your approach should be problem/solution based. Unless you can identify a software pattern that solves the specific problem you're having, you don't need it.