What would be the best way to design an OO EEPROM interface?
Hi, I am trying to design a program in which a controller needs to process information and then store calculation results in EEPROM. I am struggling to determine the best way to design this part of my program. It is written in C++ and thus it is object oriented. In the scenario below, objects are in CAPS and their relationships are specified with arrows.
MAIN FSM -----sends data for computation-----> CALCULATOR --------sends results------> EEPROM IF
MAIN FSM <-----uses stored results to send it to other objects for other purposes----- EEPROM IF
I am considering 3 options to design this program. I am looking for help to determine the best way to go and help me understand why one option would be preferable over the others...
OPTION 1: My main state machine could need to access data stored in the eeprom, either to send it to a UI object that could display it on a user screen for example, so I was thinking the EEPROM interface object should be contained in Main FSM. But that means the calculator results, which would be private data from the calculator class, would need to be sent back to main FSM for it to then store this information in the eeprom by sending it to the eeprom IF object. That sounds like a very poor choice.
OPTION 2: I could create a pointer to an eeprom interface object inside the calculator object, so when a calculator object finishes a calculation, it can interact with eeprom internally and would not need to pass it along to main FSM..
OPTION 3: the eeprom interface being a simple interface with simple members like write() and read(), and an i2c address and basic info to access a EEPROM chip, I could create a EEPROM IF object in MAIN FSM and a second one in the calculator object, so both would access the same eeprom chip in their respective scope...
Thanks a lot!
MAIN FSM -----sends data for computation-----> CALCULATOR --------sends results------> EEPROM IF
MAIN FSM <-----uses stored results to send it to other objects for other purposes----- EEPROM IF
I am considering 3 options to design this program. I am looking for help to determine the best way to go and help me understand why one option would be preferable over the others...
OPTION 1: My main state machine could need to access data stored in the eeprom, either to send it to a UI object that could display it on a user screen for example, so I was thinking the EEPROM interface object should be contained in Main FSM. But that means the calculator results, which would be private data from the calculator class, would need to be sent back to main FSM for it to then store this information in the eeprom by sending it to the eeprom IF object. That sounds like a very poor choice.
OPTION 2: I could create a pointer to an eeprom interface object inside the calculator object, so when a calculator object finishes a calculation, it can interact with eeprom internally and would not need to pass it along to main FSM..
OPTION 3: the eeprom interface being a simple interface with simple members like write() and read(), and an i2c address and basic info to access a EEPROM chip, I could create a EEPROM IF object in MAIN FSM and a second one in the calculator object, so both would access the same eeprom chip in their respective scope...
Thanks a lot!
Sounds to me like a "classic" MVC (Model-View-Controller) instance.
The "model" would be the EEPROM itself (or, more specifically, the class that implements the interface to the EEPROM), the "view" would be the class that represents your UI (it receives status updates† from the "model" class and it may trigger computations on the "controller" class on user request), and the "controller" class encapsulates the computations you need to do (may read or write status/data from or to the "model" class).
https://i.imgur.com/X3elSrd.png
† I think you should consider using the "observer" pattern here
The "model" would be the EEPROM itself (or, more specifically, the class that implements the interface to the EEPROM), the "view" would be the class that represents your UI (it receives status updates† from the "model" class and it may trigger computations on the "controller" class on user request), and the "controller" class encapsulates the computations you need to do (may read or write status/data from or to the "model" class).
https://i.imgur.com/X3elSrd.png
† I think you should consider using the "observer" pattern here
Last edited on
Your concern doesn't make much sense to me. Effectively you just want to write some data to memory, which is as simple as calling write() and passing some address information. You shouldn't need to perform challenging object-oriented contortions to just call a single function.
If you really have an EEPROM class for some reason, declare one object or a few, wherever they're needed, call your function, and move on. Alternately, it seems quite reasonable to simply make the existing interface global.
If you really have an EEPROM class for some reason, declare one object or a few, wherever they're needed, call your function, and move on. Alternately, it seems quite reasonable to simply make the existing interface global.
Last edited on
Topic archived. No new replies allowed.