Code Structure & State Management

Since the structure of the application and the user's actions revolves around tasks (keystone decisions), it feels right to build the structure of the code around these as well. To do this, I decided to make a Task class that contains all the information for a task, including the task's name and references to relevant modules.

A singleton contains all tasks and can perform operations like setting the current task or incrementing to the next task.

Tasks need to have a lot of control over the application state, and be referenced to see what gets displayed and calculated. Essentially a task acts the way a game cartridge would in a gaming console - you slide on in and you could have a totally different game, but it is still controlled using the same way (a controller) and still communicates information to the user using the same methods (a screen/sound).

Different events act upon the task

Different events (in the game console metaphor, controllers) will act on the task. It's important for each task therefore to have a function to handle any of these events. Creating an abstract Task class to inherit the other task classes from helps keep this organized.