SOLID Principles

SOLID is an acronym for 5 design principles -coding standard- which compiled by Robert C in the 1990s. All developers should have a clear concept for developing software in a proper way to avoid bad design. It was promoted by Robert C Martin and is used across the object-oriented design spectrum. When applied properly it makes the code more extendable, logical, and easier to read testable, maintainable, and helps in saving backward compatibility.

These principles provide us with ways to move from tightly coupled code and little encapsulation to the desired results of loosely coupled and encapsulated real needs of a business properly.

When the developer builds software following the bad design, the code can become inflexible and more brittle, small changes in the software can result in bugs. For these reasons, we should follow SOLID Principles.

It takes some time to understand, but if you write code following the principles it will improve code quality and will help to understand the most well-designed software.

SOLID is an acronym of the following.

• S: Single Responsibility Principle (SRP)
• O: Open closed Principle (OSP)
• L: Liskov Substitution Principle (LSP)
• I: Interface Segregation Principle (ISP)
• D: Dependency Inversion Principle (DIP)

I’m going to try to explain SOLID Principles in the simplest way so that it’s easy for beginners to understand. Let’s go through each principle one by one:

1- Single Responsibility Principle (SRP)

SRP says “A class should have one, and only one reason to change.”, One class should only serve one purpose, this does not imply that each class should have only one method but they should all relate directly to the responsibility of the class. All the methods and properties should all work towards the same goal. When a class serves multiple purposes or responsibilities then it should be made into a new class.

The Single Responsibility Principle gives us a good way of identifying classes at the design phase of an application and it makes you think of all the ways a class can change. A good separation of responsibilities is done only when we have a full view of how the application should work.

Make no mistake, there is a principle like that. A function should do one, and only one, thing. We use that principle when we are refactoring large functions into smaller functions; we use it at the lowest levels. But it is not one of the SOLID principles, it is not the SRP.

Let’s check this with an example.
Please have a look at the following c# code:

The above class violates the single responsibility principle. Why should this class retrieve data from the database? It is related to the persistence layer. The persistence layer deals with persisting (storing and retrieving) data from a data store (such as a database, for example). So it is not the responsibility of this class.

The next method format is also not the responsibility of this class. Because we may need different format data such as XML, JSON, HTML, etc.

After refactoring the code will look like this: