I have a project in C that I'm looking to convert to C++. The project does white box hardware testing of a device (actually many similar devices). In this case the device has two processors. Each have unique capabilities and both have some similar features (discrete io and such). The top level test code is a collection of exported functions from a DLL.
Looking at the code knowing that I'll have to support additional variants of the devices I have the following questions which made me think others would have suggestions on architecture/design and the reasoning behind those design choices will help others:
Do you support a device class with members proc_a and proc_b (has a thinking) with the interface having distinct function names so it's clear to the user what's being manipulated or prefer the interface to have a more generic naming scheme (like setDiscrete which takes an enum encompassing both processors' discrete a (DISCRETE_PROC_A_x and _B_x)?
Knowing that future variants of the device will have updated processor(s) how do I keep the changes to only those features that changed? I.e. A new processor B adds functionality and the include files for that functionality (from the embedded source) are different then what is used so far. I'm thinking I make the processor a class and than children of it to handle this concern. Is there a more maintanable design? What if the interface for that class needs to change but the same functionality is needed?
Tell don't ask is great but when you need setters or getters do you prefer set/get, push/pull, set/clear, etc? Do you make some communicate with the device and cache the state in your class? If so, is that separate fetch function and you use a state tracking variable or is it another function in the interface?