OO Class Organization

N

n64man120

2[H]4U
Joined
Jan 11, 2004
Messages
3,498
I was wondering what thought process some of you go through when organizing classes and their hierarchies in an OO design? I'm doing my first major embedded project, while I'm strong at programming I don't have much education regarding computer science ideology.

For instance, I'm doing a basic subset right now that is a clock component. I have a Real Time Clock device, so I thought I should create a class to encapsulate those functions and setup parameters. Then I also have a I2C class, which needs to be used in the RTC class to communicate with the physical device.

Both objects are created on the same level of hierarchy, my thought is that I should be initializing the I2C object first, and then passing a pointer to it as part of my RTC object creation, so the RTC class can access its sibling class. I've run into several challenges like this, I don't know if I'm over thinking the problem at hand, or missing the idea of how objects should be built on each other, or doing it exactly right.

Another example would be the class for my LED clock display, I want the RTC to update it, but it doesn't seem logical to have it simply be a subclass of a totally different component. Again this idea of passing one sibling object pointer to the other object comes to mind.

So, any words of wisdom from experience designing systems like this?
 
Something that has been a little bit tricky for me to learn is the ability to step back and see what the real root entity is.

What I work with a lot are exports of auto liability insurance claims for our clients. I built a big object model as an interface into the database for a large risk management software package we sell.

So, what is the real parent? Well, it wasn't a claim, it was actually a company (my client), which had claims, which had claimants, which had financial activity. But maybe it wasn't even a company...maybe it was something like a data object with activity logging to track claim activity for subsequent monthly export.

OTOH, maybe this is a one shot deal and it isn't helpful to factor out code to that degree in case of future reimplementation (to allow seamless changes to data or functionality objects without breaking using code.

So, maybe you fundamentally are working with something like a HardwareInterfacedClock, which contains functions or function prototypes of things related to keeping time and talking to hardware (and maybe even those two need to be separated).

It's just really hard to say without being intimately familiar with your task, and even then there can be more than one "correct" answer IMO.

All that said, I really think the way you're approaching it is very reasonable and will probably work just fine. How far you break it apart has a lot to do with lifecycle, because a little more work isn't necessarily worth it if it won't save you any time later.

There are far more knowledgeable folks around here who can provide way better advice than this, but that's at least how I try to approach things keeping in mind I'm working in a pretty different corner of software development.
 
Try to relate your objects to real world objects. This will help with understanding what functions the objects should have. Also, keep your objects simple, especially when starting out. In your case you might have a basic object such as a Clock class. Whenever you can say an object "is a" then you will want to inherent the parent class. If you have a base Clock class then you might have a Digital Clock class and an Analog Clock class because a Digital Clock "is a" clock. Your Digital Clock might "have a" LED display or "has a" radio so you will probably have other classes for LED and Radio.

I hope this helps a little. Gotta go to work!
 
So when you say "have a", do you mean it would essentially be a sibling class? This is the sort of case I have been toying with, I guess the best way would be to have a LED display class, a radio class, create objects for them, and then pass references to those in when creating the clock object so it can manipulate them? Either that, or creating the objects within the clock class.
 
You might want to look at some UML tutorials, specifically areas of obect relationships (has a, is a, etc)
also look into use case diagrams.

Using those help me out in determining how to organize my classes and interfaces
 
Remember, it is really easy to refactor now-a-days if you get it wrong first time around ^_^
 
You must log in or register to reply here.
Back
Top