The S.O.L.I.D. Principles

S.O.L.I.D The First 5 Principles of Object-oriented design (OOD) by Robert C. Martin.

S.O.L.I.D stands for

• Single-responsibility principle (SRP)
• Open-closed principle (OCP)
• Liskov substitution principle (LSP)
• Interface segregation principle (ISP)
• Dependency inversion Principle (DIP)

Get knowing the S.O.L.I.D principles is very helpful to make design more flexible software and changing the way that we write software. We can use this method to make the design more easy to maintain, extend and understandable.
Also, We would all like to work on the design that is easy to reduce their complexity, but achieving such simplicity is not always easily done. This is because unnecessary complexity can creep up on us without anybody noticing by using these principals.

Single-responsibility principle (SRP)

“Classes should be having one and only one responsibility”

Why should we use the single responsibility principle?

The main benefit of this approach is that it makes our software easier to implement and more easy to change code for future changes.

Let's discuss an example...

For example, say we have an Employee class and we wanted to if the Employee is eligible for promotion this year and calculates the income tax he has to pay for the year. Well, this is pretty simple right...

Actually it is not a responsibility of the Employee owns. That owns the Company’s HR policies and finance department’s responsibility.

So, Employee class should have the single responsibility of maintaining the core attributes of an employee.

Let's move the promotion determination logic from Employee class to the HRPromotions class like this :

Similarly, let's move the income tax calculation logic from Employee class to FinITCalculations class,

Our Employee class now remains with a single responsibility of maintaining core employee attributes,

Open/Closed Principle (OCP)

Let’s begin with a definition of what the Open/Closed Principle is,

“classes should be open for extension but closed for modification”.

What is means is that, if the class Employee is written by the developer Tom, and another developer also wants to do some modification, Then that developer extending class Employee and do the modification. But actually not modifying class Employee,

It uses interfaces instead of superclasses to allow different implementations which you can easily substitute without changing the code that uses them.

It is like a Recycler view and an adapter class, Developer create own adapter with customer behavior by without modifying existing recycle view. The interfaces are closed for modifications, and you can provide new implementations to extend the functionality of your software. An interface introduces an additional level of abstraction which enables

Why should we use the Open/Closed Principle?

It promotes the use of interfaces to introduce an additional level and enables you to adapt the functionality of your application without changing the existing code.

Liskov substitution principle (LSP)

“ Objects should be replaceable by their subtypes.”

This principle was defined by BarbaraLiskov. This has a strong relationship with the Open-closed principle. The violation of this principle is considered a violation of the open-close principle too by Robert C. Martin. This extends the behavior of the open-closed principle by focusing on super and subclasses.

The subject of the superclass should behave as same as the subclass. Superclass subjects should be replaceable in a subclass without breaking the code. It means that subclasses need to behave the same as the parent classes. Child classes should perform all the basic functionalities of the superclasses, also there should not be unimplemented methods and after overriding subclasses, they should not give different meanings to the existing methods of superclasses.

Interface segregation principle (ISP)

This principle suggests that,

“A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use”.

This principle talks about interfaces. As in a single responsible principle, interfaces also should be split into small specific interfaces. Once an interface is too large, it’s called a fat interface. By following this principle you can avoid bloated interfaces. This interface will be defined by clients as the client knows about what is related to him. If you write methods that are not necessary, then the developers will have to implement them and include them in interfaces. So, the client will have to interact with them, which are not needed. That’s what this principle is explained. That client should not be forced to interact with unwanted interfaces.

Dependency inversion Principle (DIP)

“ Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions. ”.

The dependency inversion principle is based on the open-closed principle and the Liskov substitution principle. This principle depends on two rules,

1. High-level modules should not depend on lower-level modules. Both should depend on abstraction

2. Details should depend on abstractions, while abstractions should not depend on details.

It means that a high level should not be affected by changing the lower-level module. Also, these modules do not work directly with each other, they use interfaces as the abstract layer.

Having an object of an interface which helps us to communicate with the concrete classes. What do we gain from this is, we hide the actual implementation of class A from class B. So if class A changes the class B doesn’t need to care or know about the changes.
EX: Three tire architecture

Conclusion

If you’ve got any other good and straight forward examples of the S.O.L.I.D principles I’d love to hear about them.

Thank you.

See, you soon…