Designing a class structure, redux

[Daklu]

Earlier I had a question regarding class design that MikaelH kindly answered. Now I have a related, but more complex problem.

I have four "toasters" I need to test: Toast Magic, Super Toast 2k, Super Toast 3k, and Toast All. Three of the toasters communicate to the host computer via an I2C interface while one, the Toast All, communicates via a USB/serial UART. That creates an issue in that the TA toaster has a very different communication process. The I2C toasters continually check the state of the toast and update their internal registers to reflect the current state. The TA toaster continually checks the toast state and sends it out to the serial port. If the UART has been initialized each toast state is stored in a buffer that will be dumped all at once at my next read, which may not be for quite some time.

Furthermore, there are potentially three different devices we will use for I2C communication. All can do basic read and writes, but each has it's own unique feature set. The 8451 can operate only in master mode, the Aardvark can do master or slave as well monitor the bus (in case the blender wants to talk to the food processor), and the Corelis do everything the Aardvark can as well as fiddle with low level bit timing.

Here's a UML diagram of what I'm thinking of doing. (I don't really know UML, so some of the notation might be incorrect.) I've also attached a copy of the Visio diagram if anyone wants to modify it.

Explanation: Each I2C interface class inherits from an abstract I2C Interface Base class. Each toaster class inherits from an abstract Toaster Base class, which inherits from an abstract I2C Slave Base class. The I2C Slave Base class contains the I2C Interface Base class as part of its private data.

Whew! Enough with the problem description. On to the questions...

1. The I2C Slave Base class contains the I2C Interface Base class, but the Interface Base class is abstract and should not be instantiated. Does this cause problems?
   
2. Currently I have the Toast All toaster inheriting from the I2C Slave Base class even though it is not an I2C device. My thought is to simply override the I2C read and write methods and have them use the serial port instead. On the other hand, having a serial device inherit from an I2C class seems... wrong... like I'm violating the rules of OOP. It would be possible to put the Interface Base class in the Toaster Base class or even iin the Toaster classes themselves, but I get the sense this will create more problems that I can't quite grasp right now. Also, the I2C Slave Base class will be used in other applications and other devices. The Interface Base class seems like it belongs in the Slave Base class. Comments? Suggestions?
   
3. The three I2C interface devices have different capabilities. What's the best way to expose them? One method is to take the union of all the functions and put them in the base class. The child classes could then implement those that apply to it and ignore the others. Another method is implement each unique function in the child class, but I'm not sure how accessable those functions will be to the Toaster classes. And what happens if I drop a Corelis bit timing vi on the diagram and at runtime the interface is an Aardvark?
   
4. Related to Q3, I think I need a Clear Buffer method for the Toast All toaster. Should I put that in the Toaster Base class even though it is meaningless to the other toasters?
   
5. Each toaster has very different abilities when it comes to configurations. I don't even know how to approach this... I believe they all require a write to a register to change config (except for the Toast All, which has no configurable settings) so I could simply expose the Write methods from the I2C Interface Base class and try to detect the object type at runtime so the right commands are sent. That feels very clunky though. Ideas? (Now that I've typed this out it seems like itis another variation of Q3.)
   
6. What's the significance of class names being bolded on a UML diagram? Some are, some are not. I can't figure out why.
   

(Looking over my diagram again I see I'm going to need to wrap the I2C Interface Base methods and expose them in the I2C Slave Base class. If nothing else I can say the time I spent learning what little UML I know was well spent. It has really helped me think this through.)

Any and all comments are welcome!

[MikaelH]

Hi

I've made a quick UML diagram of how I would have solved the design.

When I get more time I'll try to give you more feed back.

Remember that all base class methods should makes sense to the child classes.

Cheers,

Mikael

[LAVA 1.0 Content]

QUOTE (MikaelH @ Jul 21 2008, 12:57 AM)

...

Remember that all base class methods should makes sense to the child classes.

Cheers,

Mikael

Thanks for that reply Mikael!

For self-taught (ah-hem, cough cough) OO types like myself, snippets like this are "Golden Nuggets".

Thank you!

Ben

[Daklu]

QUOTE (MikaelH @ Jul 20 2008, 09:57 PM)

Hi

I've made a quick UML diagram of how I would have solved the design.

When I get more time I'll try to give you more feed back.

Remember that all base class methods should makes sense to the child classes.

Cheers,

Mikael

Thanks for the response Mikael. I ended up implementing most of the structure over the weekend and did almost exactly what you suggested. The only difference is that I didn't create a Toaster I2C and Toaster Serial class. Instead I just made the I2C Slave class a member of the Toaster classes that use I2C and I'll implement the serial protocol directly in the Toast All class.

I think this will work okay. The only problem I can see right now is how to configure the I2C interfaces and Toasters. You suggested a pop-up configure dialog box in the other thread so I'll probably go that route.

http://lavag.org/old_files/monthly_07_2008/post-7603-1216650634.gif' target="_blank">