SOLID - OOPS/OOAD Principle

SOLID - OOPS/OOAD Principle

The Object Oriented concepts in all OOPS language follow some common principles. These principles are guidelines for developers and architects which they need to understand as they grow their understanding of the language.

The SOLID principles are the most talked about in the Enterprise Java world. These principles deal with cohesion, coupling, inheritance, abstract types in the Object Oriented Analysis and Design (OOAD)

The five principles are also asked about in Java or JEE interview. SOLID is an acronym for 5 principles of the Java language which are listed here:

1) S - Single Responsibility Principle: This principle is very closely related to the highly cohesive design methodology. This principle says that each class, method and variable should have single responsibility to perform. If there are multiple responsibilities assigned to a class then it becomes very difficult to maintain as the Java application scales. So sufficient time should be given to think what responsibility will be assigned to which class, method or variable.

2) O - Open Closed Principle: This principle says that when a class is inherited by other class then the superclass should not be a candidate for change just because it is going to be inherited by some other class. Thus it can be said that a class may be open for inheritance but closed for change because of inheritance.

3) L - Liskov Substitution Principle: This principle says that when multiple classes inherit or implement a class/interface and we have reference of super type which references to an object of one of the sub type then changing the subtype object from one class to another should not make any change.

Vehicle v = new Suzuki();

v = new Benz();

The change of object in the above Java sample code should not make any change to the various methods being invoked other than the fact that the methods will now be invoked on Benz object instead of the Suzuki object.

4) I - Interface Segregation Principle: This principle says that instead of having a big fat interface or class, split the functionality into multiple parts.This is different from the Single Responsibility Principle because even if a class has a single responsibility, it can be split into multiple parts for better understanding and maintainability. One common method to split a fat class is to make it implement/inherit other thin interface/class.

5) D - Dependency Inversion Principle: This principle is very much similar to the Open Closed Principle it states that the super type should not be dependent on the sub type but the sub type should be dependent on the super type. The above is possible if abstract entities are super types and concrete types as sub types. The sub types can anytime changed without affecting the super types.

Here is the analysis for the above discussion:

S and I are similar but with the difference that I can be used when S makes a single class grow fat. I have seen some classes having 2000 lines of code and 10-15 methods. It really makes life Hell

O, L and D are similar but O to not changing the super type just because of inheritance relationship, L asks us to make sure that multiple sub type objects are substitutable for a reference of super type and D emphases on coding to interfaces or abstract classes