Application Layer

[nperozzi]

The idea of the timer_t class was that it should be as simple as possible. That way we wouldn't need to update it, and its unit tests would still hold.

With more state (variables) added to the object, it becomes more complex and more difficult to test. The tests we've already created do not help as much. And the object doesn't do only what was initially intended anymore (just keeping time). This is a code smell:

Large Class - Class trying to do too much and has too many instance variables^1

I think it would be wiser to try to add another layer of state, an application state:

classDiagram
    class application_t {
        state_machine_t state_machines[MAX_TIMERS]
        uint8_t current_timer_index
    }
    application_t --> state_machine_t

    class state_machine_t {
        state_t state
        timer_t timer
        uint16_t millis_of_last_transition
    }
    state_machine_t --> timer_t

    class timer_t {
        uint16_t original_time
        uint16_t current_time
    }

The application would manage what timer is active, and what to show on the display. Adding an abstraction like that even makes it easier to test!

_Originally posted by @emanuelen5 in https://github.com/emanuelen5/kitchen-timer/pull/42#discussion_r1678294955_

[nperozzi]

After a failed attempt to write the application layer, we agreed it would be best to decide how it should look before I start writing some code 😅 . This issue aims to do that: agree on what the application layer should do and what the structure should look like.

[nperozzi]

From our conversation yesterday, this is what I understand:

What should that application layer do?

• Handling the display logic: It decides what state machine is displayed at a given time.
• Decides which state machine gets affected by each event. Example 1: a SINGLE_PRESS would affect only the state machine displayed (current_state_machine) but not the others. Example 2: the SECON_TICK affects all state machines in a RUNNING state.

Other considerations:

• The application layer is not another state machine. It does not handle states.
• When a state machine goes into state RINGING, it can have a flag that informs the application that it needs to become the current state machine and be displayed.
• The debugging printf can remain in the state machines. If a variable within the application struct is needed in the printf (for example current_state_machine_index, the application can be passed to the state_machine as a call-back ( following the principle of "Dependency Inversion")
• Keep the "Law of Demeter" in mind: "Objects only talk directly to their immediate objects" Otherwise, to retrieve information, a function needs to be created.

While writing this, I think how much I may have misinterpreted 🤣.