design patters - 2darray.com

We all know what are the pros and cons of Object Oriented Programming, but what about writing better codes? What about making it more flexible and easier to read? Well, here are some tips on SOLID Design Pattern and the easy thumb rules to keep in mind while coding.

I am personally focused on how to use SOLID principles with some practical approaches, rather than understanding the huge theoretical knowledge. So, below I have tried to explain the approaches as simplified as possible. I am a strong believer of starting with something and then improvising on my own.

Single Responsibility Principle :

The first principle of SOLID Design Patterns is as follows –

A class should have a single responsibility and one reason to change.

Single Responsibility Principle - 2darray.com
Anti-Pattern of Single Responsibility Principle

What should be done ?

Always think of the logic and the business rules which are only applicable for that class.

“Gather together the things that change for the same reasons. Separate those things that change for different reasons.”- Robert C. Martin

Open-Close Principle :

The second principle of SOLID Design Pattern is as follows –

A class should be open for extension and closed for modification.

high coupling problem - OCP - 2darray.com
Problems when your class is not extensible

What should be done ?

Write your codes in a way so that, if someone wants to add a new functionality to the class in future, he or she won’t have to touch your existing code.

Liskov Substitution Principles :

The third principle of SOLID Design Pattern is as follows –

Any object of some class in can be replaced by an object of a child class.

wrong design - LSP - 2darray.com

What should be done ?

If you have two classes, class A and class B, where B is a subclass of A, all the methods which are mentioned in class A should have implementation in class B.

Interface Segregation Principle :

The fourth principle of SOLID Design Pattern is as follows –

Clients should not be forced to depend on methods that they do not use.

Functions are mentioned but nothing implemented - ISP - 2darray.com
Problems : Client will expect it to work, but the method was not implemented

What should be done ?

Lets’ assume, I have an interface having two methods x() and y(). Two of my classes A and B implements the interface, but Class A has only the functionality of x(), where Class B has both of the functionalities x() and y(). The easiest way to solve this is, override y() in class A, and implement nothing in it… which will directly lead us to the situation shown in the gif above.

The Pattern is to create two interfaces. One will have the common functionalities and the second interface will have the extra functions (i.e. y() from the above example) and will extend the first interface. Now, when we will implement class A, we will implement the first interface, but for class B, we will implement the second interface.

Data Inversion Principle :

The fifth principle of SOLID Design Pattern is as follows –

High level modules should not depend upon low level modules. Both should depend upon abstractions.

What should be done ?

We should not extend concrete classes, we should always depend on abstractions like abstract classes or interfaces.

Please check out my other posts on Technology.