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 different subclasses, and it will evolve into a strategy object. 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"?

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"?