OOD Solid Principles
Introduction
The usage of Object Oriented principles on software solution development has vastly improved. This improvement is mainly caused by several reasons but higher software reusability and easy maintainability are ranked high among those reasons. The OOD (Object Oriented Design) SOLID principles refers to five basic principles where each letter in SOLID is abbreviated for a OOD principle.
- Single responsibility principle
- Open closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
Single responsibility
The first principle of SOLID named as “Single responsibility” gives a basic idea about the meaning of it by its name itself. The five principles of SOLID are based on proper class design where Single responsibility principle depicts that a class should have only one job. This principle avoids developers in making fragile and unmaintainable classes as this principle guides us to create classes that have only one responsibility.
Ex: Let take a class with two responsibilities of calculating area and drawing the shape. Whenever there is a change in the process of these two responsibilities the code segments have to be changed. If we separate these two into two classes it makes use the single responsibility principle practically.
Open — Closed Principle
This principle describes that objects should be open for extension but should be closed to modification. If the coding is without considering the abstraction, then the requirements which comes in future will definitely makes developers to change the code. The usage of interfaces can be seen in this principle. This let the new functionalities to be added without modifying the current code.
Ex: Defining the methods of shape class in an Interface and implementing the defined methods inside the shape class.
Liskov Substitution principle
Child classes (derived classes) should be a substitute of its parent class (Base class). In this principle it depicts that all the derived classes should perform all the basic functionalities of their base class and when overriding the methods of the base class by the derived class, it should not make a different meaning for the overridden method from its parent class method.
Robert C.Martin suggests that making use of preconditions and post conditions for each method will make this principles used practically.
Interface Segregation principle
A client should never be forced to implement methods that they do not use but, defining unused methods in interfaces, makes un on implementing the methods defined which is a waste of resources (time and etc.).
Although the methods that are unused by a particular client might be a useful method to another group of clients. So it is really important to group these methods into different interfaces in order to serve various groups of clients.
This breaking down of the interfaces goes close with composition over inheritance and decoupling over coupling.
Ex: interface shape{ interface SolidShape{
double area(); double volume();
} }
Dependency Inversion principle
The last of the SOLID principles describes that the lower level modules should not depend on higher level modules but on abstractions.
Dependency inversion have advantages like making the software reusable and increasing the flexibility of the software.
Ex: Think that we need to authenticate a user for our system which is done using external services. So there are two possible ways of carrying out this task. One is writing a code segment on authenticating the user by adapting the external services to the authenticate process and the other one is making use of an abstraction on these external services. The second option makes more sense because it allows to include new services in future without any modification of the existing code.
Conclusion
As explained above, all the five principles have their own set of advantages which are related with Object Orientation. Practically using these principles on software development makes the software reusable, easily maintainable, testable and etc.