OO Recipes

Here are my OO Recipes that I think would really cook up some good OO applications in the software world

1) Composition Vs Inheritance - Hmmm... oh well I guess every comes across this one so often so I will try my best to explain it in the simplest way possible. Inheritance breaks encapsulation by tightly coupling the subclasses with the base class so the changes in the base class must be in tandem with subclasses or else it may break the system. Composition on the other hand does not suffer from this limitation as it encourages delegation of work. Composition also promotes encapsulation.

2) Helper Classes - In my opinion if you have lots of Helper or Utility classes then you have not got your abstraction right and it indicates a poor design. Lets take a look at Collections Framework in Java.

For eg:- The AbstractCollection class that implements the Collection interface has implemented a few methods that are generic in nature to all the Collections that implement the Collection interface hence there is no need for any kind of utilty methods or classes.

3) Static methods - The use of static methods are justifed when you are using them to create factory methods or singletons or utility methods that help in remove duplication of code. Anything beyond this usage indicates a procedural mindset.

4) Singleton Good or Bad - Singletons are a good excuse for global variables. Moreover Singletons are supposed to guarantee a single instance and this is true only if you are using a unified class loader. Having said all this they are useful in maintaining the state throughout the application.

5) Encapsulation - This encourages tight coupling within the class and only exposes the stuff that needs to be exposed to the client classes. Without good encapsulation its impossible to design an application that is flexible and simple. Encapsulation encourages the principle of least knowledge.

6) Single Responsibility Principle - Every object in your application should have one single responsibility of doing something if its doing more than one thing then obviously it needs refactoring or perhaps maybe decomposing it into simpler objects.

7) Dont Repeat Yourself - If you find yourself repeating a block of code or a block of logic very often consider refactoring them by moving them to another domain object or in the worst case a utility method.

8) Polymorphism - Whenever you come across code that does conditional type checking that is a strong indication that it definitely needs refactoring. All those if else, switch statements look ugly.

9) Abstraction - If you get your abstraction right then there will be very few helper class and utilty methods around your application and there will also be high reuse of code.

10) Immutability - Immutable objects help keep your application simple and thread safe, think about it if your objects are immutable you dont have to every worry about thread safety. However some may argue that this will create unnecessary objects on the heap and yes it does but performance is something that we always look at the end. The trick here is if your application is simple and flexible then its easy to tweak it to perform well.

11) Programming to Interfaces - I have a dedicated post on this topic. Click here to read more Programming to Iinterfaces