Closed nperozzi closed 3 weeks ago
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.
From our conversation yesterday, this is what I understand:
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")While writing this, I think how much I may have misinterpreted 🤣.
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:
I think it would be wiser to try to add another layer of state, an application state:
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_