Representation invariants?

[stephaniesaab]

Hi guys, I was just wondering how are we going to implement representations invariants? I was thinking that each task should have a unique name and the deadline has to be sometime in the future and can't be in the past. Should we raise an exception like 'input error -- invalid naming, there's already a task with this name' for when people input a task?

[e-laflamme]

I think each task probably shouldn't have to have a unique name. Some people might like to name things similarly or have tasks that repeat that they'd want to name the same thing. From an implementation standpoint I think it is also unnecessarily complicated as there shouldn't be anything wrong with having tasks that are named the same. They will still have different memory addresses.

Depending on how you are thinking the user should input the date though, they could be useful. If you want the user to be able to just type in a date then it would probably be useful. However, we could also just use a drop down menu to limit selections (to chose month, day, year) and have some small method to check that the chosen date is valid.

[stephaniesaab]

In terms of the drop-down menu calendar, we can add that as a potential new feature.

[stephaniesaab]

Great point, thinking about the user experience is definitely important! My reasoning for each task having unique names is because the "complete task" method is currently using the task name as input, if multiple tasks have the same name then this will complicate the method. If we don't want tasks to have unique names, then the complete task method should take in a different input, something that is unique to each task. I can't think of any other defining attribute that would make a task unique other than its name, the deadlines, course, type of assignment, and study deadlines can very reasonably be the same. I don't think it'd be too much of an inconvenience for the user if they have each task named uniquely for the time that they're on the task list, once they're done the task they can complete it and then add another task with the same name. Do you have another suggestion for a defining attribute of a task?

[e-laflamme]

That makes sense. We could have the input to that complete task method be the task object itself. That way we wouldnt have to worry about using a attribute to define it. That is if that the code which uses that method has access to the tasks, which I assume it does if it can access the name but I could be wrong.

The UI will have to load in all the task objects to present them to the user so it should be able to pass that info to a controller and usecase which change the entities.

[XinyingXu]

When implementing the completeTask use case, I assume that when the user interacts with the UI, the controller passes the task name (String) to the use case interactor, which searches the task name in the ToDoList to locate the task. I can edit the use case so that it takes a task object as a parameter instead.