Wednesday, January 17, 2007

About software static design

People often ask me about suggestions for good class design, so I'll write this with the hope more people will find this more easily.

The concept of class comes from the social classes. Every society has always been stratified, so people is classified into one of those stratus. As such, every class has their responsibilities already defined: A hunter must hunt, a guardian must guard, a paparazzi... Well, so we now have classes with responsibilities. Cool! We have a starting point.

When designing the static part of a model (this is classes, packages...), the first thing we must identify are responsibilities. Good, now we have a set of responsibilities identified but, what do we do with them?
The answer is easy: Define classes.

Societies have needs, and must have responsibles to be in charge of them. So people is classified according to their capabilities and skills to be responsible of those needs. A class is defined by both their abilities and responsibilities. We have the latter, and we're to find the best abilities to take charge of them.

Now our point has become just to find the best design for those abilities, but that falls outside of the scope of this rambling.

One more thing to remember. People usually burns (nope, no spontaneous combustion here; just metaphorically speaking) when they're assigned too much responsibilities. They will become unstable, hard to maintain and keep under control, and most probably, attack you. And so classes do. Try to keep their amount of responsibilities low (I've found the "two responsibilities per class at most" rule quite useful). If you can't, delegate some responsibilities on a different class, just like people do. I'm 99.999% sure you can do it!

Those are just my thoughts about defining classes. You might disagree, of course, but this reasoning has worked great for me in these last years, so I suggest you to give it a try :)

No comments: