• p5 - exemple de lecture de l'adresse email : il y a des guillements en trop

new FileReader(FICHIER_EMAIL)   // au lieu de new FileReader("FICHIER_EMAIL")

• L'énoncé ne parle pas des assesseurs. Si les setteurs sont totalement inutiles, les getteurs pourront s'avérer utiles pour vos tests unitaires.
• Pour répondre strictement à l'énoncé, il n'est pas nécessaire que cette classe redéfinisse la méthode equals(). Toutefois, c'est nécessaire pour les tests de la classe TodoList. On pourra ainsi sauver une liste, la relire et vérifier qu'on obtient bien la liste de départ.

• Le constructeur construit une liste vide.
• A coté de la méthode save(), prévoir aussi une méthode load() qui lit le fichier.
• Ici aussi, une méthode equals() sera utile pour les tests unitaires.
• Une méthode int size() qui donne le nombre de todos dans la liste est également utile pour vos tests unitaires.
• Il en est de même de la méthode boolean contains(TodoItem todo) qui vérifie qu'un todo se trouve bien dans la liste.
• Lorque vous aurez implémenté la méthode load(), la compilation affichera le message suivant

$ javac TodoList.java
Note: TodoList.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

C'est tout-à-fait normal. Le compilateur indique en substance qu'il ne peut pas être sûr que la liste qu'il va lire contient bien des TodoItem.

• Dans le diagramme de classes de l'énoncé, les méthodes (newAndExit(), ) ne reçoivent pas de paramètre. C'est une simplification du diagramme. Il est évident que ces méthodes doivent recevoir des paramètres. Par exemple, la méthode newAndExit() recevra en paramètre l'adresse email à sauver dans le fichier.
• Certaines parties de code sont communes entre les différentes fonctionnalités. On vous encourage évidemment à découper votre code plutôt que de le dupliquer.