Object Oriented Principles

Hi friends!!!!☺
Today we'll be looking into a different yet interesting area in Software Engineering. Yes, today we are going to look at the "Object Oriented Principles".We also call this as S.O.L.I.D, the first 5 principles of object oriented design principles.This was introduced by Michael Feathers. Object Oriented Principles help the programmers to build quality system which can be maintained and extended easily over time.

S.O.L.I.D  stands for ,

              1. Single Responsibility
              2. Open Close Principle
              3. Liskov Substitution
              4. Interface Segregation
              5. Dependency Inversion

Let's take a look at each of these principles in detail.

1. Single Responsibility

A unit (class/function/module/API) should have one and only reason to change or only one responsibility. If there are more than one reason to change the unit must be separated into atomic units which will have one and only responsibility.

Single responsibility concept


A class(unit) having more than one responsibility


Why Single Responsibility???
Because over time if there are any changes to be done for a unit and if it has more than one reason to change or more responsibilities it might affect the other units as well. So in order to avoid the complexity we should allocate one responsibility for one unit.

2. Open - Close Principle


"Objects or entities should be open for extension, but closed for modification".
In real world requirements aren't static. They'll keep on changing. So if we are to modify our codes based on the changing requirements it is going to be really complex. So that instead of modifying the code if we are to extend the code it would make things much more easier. For example finding the total area of different shapes will be difficult if the type of each shapes keep on changing. So we can simply have the area calculating method as an abstract method in one class and extend it according to the different types of shapes. Here we are closed for modification and opened for extension. 

Open close principle in coding level

3. Liskov Substitution Principle

"Every subclass/derived class should be able to substitute their parent/base class".
The child class should override all the methods in the parent class but should not give different meaning. 


In the above example Rectangle is the parent class and Square is the child class.  Rectangle class has a method called calculatePerimeter(). Since Square is the child class it has to override all the methods from Rectangle class. But as we can see the implementation for calculatePerimeter() in parent class is different from the implementation for calculatePerimeter() in child class. So it is clear that this code is violating the Liskov Substitution principle.

4.Interface Segregation Principle

"Clients should not be forced to implement methods they do not use".
While implementing, make sure that each methods in the interface is required by the client, if not then group the methods into different interfaces based on the clients who are going to use them.

Fat interfaces - Interface that has unnecessary methods which won't be used/needed by the clients.



5. Dependency Inversion Principle

"Higher level modules should not depend on lower level modules, but they should depend on abstractions(reduce coupling)".

Normally high level classes contain complex business logic while low level classes contain basic operations. So we develop the high level classes once we are done with the low level classes, which means the high level classes are highly dependent on the low level classes. So if there are any changes in the low level classes it will heavily affect the upper classes. So in order to avoid that we have "abstraction layer" between low level and high level classes. So that high level classes ill not have direct interaction with low level classes. Instead both classes will depend on "abstract layer" (simply an interface). Based on abstract layer low level classes will be built. This principle should be used for systems that has rapidly changing requirements.

Comments

Popular posts from this blog

Encryption to take secure programming a step forward

RMI - Weather station

Hashing... First Step to Secure Software Programming