Which design pattern should I use for a TODO list in Java?

Question

Which design pattern should I use for a very simple Object-oriented todo list?

Initially I started off with classes for Task, TaskList, Driver. Also a simple UI displaying a list of the Task titles. I was struggling to have the UI update the list when new tasks were added, and in trying to solve this I realised my whole layout was probably wrong.

I'm looking for someone to give me a basic direction, or perhaps a link to a design pattern diagram with a little guidance on how my classes relate to the diagram.

Thanks.

Answer 1

I think you want the observer pattern - but take a look at this previous stack overflow question http://stackoverflow.com/questions/744762/should-i-use-a-listener-or-observer

Answer 2

The Model-View-Controller (MVC). Basically, the Model stores the task, the Controller handles the events and the View the display. You can have several view, i.e. one to display the tasks in the UI, and one to save to disk.

Answer 3

Another piece of advice: Assuming you're writing your UI in Swing, do not use DefaultTableModel and copy Tasks from your TaskList into the model (i.e. do not hold your data in two places). Instead, subclass AbstractTableModel and have it act as a thin wrapper around the TaskList; e.g.

public class TaskTableModel extends AbstractTableModel {
  private final TaskList taskList;  

  public TaskTableModel(TaskList taskList) {
    this.taskList = taskList;
  }

  public Object getValueAt(int row, int column) {
    Task task = taskList.getTask(row);
    Object ret;

    switch(column) {
      case 0:
        ret = task.getStartTime();
        break;
      case 1:
        ret = task.getState();
        break;
        // etc ...
    }

    return ret;
  }

  // TODO: Implement other TableModel methods.
}

Answer 4

The general architecture should implement the Model-View-Controller (MVC) pattern (or Model-View-Presenter with a stronger decoupling of model and view) , and it looks, like you started with that already. You have classes, that represent 'the task' and 'the tasklist' and you have an UI to present the tasklist (the model) to the user. Now you need an interface (or a set of interfaces) for the model and the ui and you want to make sure, that the model does not know the ui and the ui does not know the model.

Because in between, you have the presenter class(es), that will react on model changes and ui events (Observer pattern, databinding as a technique). It can listen to the model and update the view. So you want to make your model observable. And it can listen to events from the view (value edits, actions) and pass this information to the model, so it can (try to) adapt to the user intended changes (the model and only the model will validate the user input and give a response to the presenter).

Yes, it is quite complex. To start off, break your application into the three parts (model, view, controller/presenter) and make the model observable. So you can start easily with a view that is automatically update when the model changes. And then, step by step, you could add functionality to react on user inputs on the UI.