Object Orientated Design Principals

Via this series of postings, I intend to explain, some of the object orientated design principles that I believe to be key in design and then writing good software. I will try to explain all the reasons the principals are important and give some example of implementation using Java and/or C# code examples.

The best place to start, clearly up the issue of OO design Principals and Patterns. Principals and patterns work hand in hand but are not the same thing. For now, I am going to explain a pattern to you as a blue print that suggests you have a certain class in a certain place and that class has a given behaviour.

The design principals are a set of best practices as to how to build that class or package to deliver the behaviour as suggested in the pattern. In fact, OO design principals apply to classes and packages and are not applicable at the system or component level.

So let us start with classes and the first principal that comes to mind is ‘Single Reasonability’. Like that sense from city slickers where Curly tells Billy Crystal the secret to life is just one think. So it is the secret to a class, it is just one thing. Every class needs to be reasonable for just one think. In fact, as you will see so much off OOD hangs off this premise.

Therefore, what is a single reasonability and what defines it? I have seen some people define it as action; therefore, a class must perform no more than one action. I prefer to definite it as a single change, if you can come up with more than one reason a class would need to change then it has more than one reasonability.
Wow, that is big call, does that mean if a class has three methods then it needs to be refactored into three classes? Yes if more than one reason or specification change could cause the class to change.

Looking at the classic modem example will shed some light on this concept. We start with a class with four methods namely ‘dial, hangup, send and receive’. These methods within one class appears reasonable, they are all actions that the modem performs, hence a logical grouping.



Looking deeper, we can see really two sub groups, namely methods to handle the connection ‘dial and hangup’ and methods that handle data transfer ‘send and receive’.

Should there be a change to the way the modem class handles it connections, in the present structure the code surrounding the transfer functions would come under potential change.

So it justifiable to separate out the connection methods from that of the data transfer in doing this one decouples the class further and proves more ‘future proofing’.



One way to achieve this is interfaces, one for the connection type methods and other for data transfer type methods. The result is that changes in the class that implement the interface are hidden away from the rest of the application.
The second method is to create a super class known as modem which inherits from connection sub-class and data transfer sub-class. This solution is not perfect for reason that will cover in this next posting.