SOLID: 5 basic principles of Object Oriented Design

Solid is an acronym invented by Uncle Bob to establish the five basic principles of object – oriented design and programming. This acronym has enough relationship with design patterns, especially with high cohesion and low coupling.

SOLID (single responsibility, open-closed, Liskov substitution, interface segregation and dependency inversion

The goal of having a good programming design is to cover the maintenance phase. Which is more readable and easy to understand and new features can be added without having to change greatly so called old code . Maintenance costs can cover 80% of a software project so that is why we appreciate good design. Also read our guide on How to write better code.

S- Stands for SRP (Single Responsibility principle)

This principle is used by each class to a simple and specific purpose. Many times we are tempted to put a reusable method that have nothing to do with class simply because it uses and catches us at hand. At that time we “Since we’re here, so I’ll create a class to do this. Directly I put it here.”

The problem arises when we need to use that same method from another class. If not refactor at that time and a class designed for creating purpose of the method, we will run long – term classes perform tasks that should not be their responsibility.

With the above mindset we find, for example, an algorithm formatting of numbers in a class designed to read from the database because it was the first place where it was first used. This leads to be difficult to detect and find methods so that the code is to have it memorized in the head.

O- Stands foe OCP (Open/Closed principle)

Principle attributed to Bertrand Meyer speaks of creating extensible classes without having to enter the source code to modify it. That is, the design must be open for extend-ability but closed to be able to change. Although this sounds easy, it is difficult to predict where should extend and will not have to modify it. To achieve this principle must be clear how it will work the application, which can be extended and how they will interact classes.

The most common use of extension is by inheritance and re-implementation of methods. There is another alternative is to use methods that accept an interface so that it can run any class that implements this interface. In all cases, the behavior of the class changes without that we had to play internal code.

As I mentioned there comes a time when the needs can become so unpredictable that we encounter with the methods defined in the interface or extensible methods are not sufficient to cover the needs. In this case there will be no choice but to break this principle and refactor.

L- Stands for LSP (Liskov substitution principle)

This principle was created by Barbara Liskov and talks about the importance of creating all derived classes. So that they can also be treated as the base class itself. When creating derived classes we must ensure and not re implement methods that make the methods of non-function base class as if they were an object of that base class.

I – Stands for ISP (Interface segregation principle)

This principle was formulated by Robert C. Martin and is something like the first principle. When these interfaces should be specific for a particular purpose are defined. Therefore, if we have to define a set of abstract methods that you must use a class through interfaces, it is preferable to have many interfaces that define few methods that have an interface with many methods.

The aim of this principle is mainly to reuse the interfaces in other classes. If we have an interface that compares and cloned in the same interface, more complicated way may be used in a class that should only compare or another that should only clone.

D- Stands for DIP (Dependency investment principle)

It was also defined by Robert C. Martin. The aim of this principle classes get uncoupled. In any design must always be a link but must be avoided as far as possible. An uncoupled system does nothing but a highly coupled system is very difficult to maintain.

The aim of this principle is the use of abstractions to get one class interact with other classes. Without being know directly. That is, the top – level classes should not know the lower level classes. In other words, you do not know the details. There are different patterns such as dependency injection or service locator that allow us to reverse the control.

Leave a reply