What Is SOLID And Why SOLID In C#

SOLID Introduction

SOLID is a superset of 5 principles. These principles are basically used to design the application which will help to simplify the development and make that maintainable and testable.
The SOLID acronym was first introduced by Michael Feathers.
With the use of SOLID principles, most of the software design problems get solved as these are based on the very basics of the Object-Oriented programming. As everything in the application will be treated as Object, there should some rules to use it.

SOLID Acronym

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) – Not Dependency Injection

Now, let’s see each principle in detail including basic understanding and definition.

Single Responsibility Principle

Robert C. Martin says about the principle that, “A class should have only one reason to change”
Each class or module must have only one responsibility, should not mix or combine with other tasks or responsibility or responsibilities. So when lonly one responsibility needs to be carried out, there will be one or a single reason to change it.
It means that every class should represent only one entity and should not contain mixed properties. For example, if a class is “EmployeeDetail” then it should contain only basic details of the Employee. It should not contain properties or details of Payment.

Open/Closed Principle

“Software entities should be open for extension, but closed for modification”
This situation mostly comes when we get change requests after the implementation of the functionality. In this case, we must not change or modify the existing class as it is already gets used, and if we try to change the existing class then there will be the need of retesting functionality which is already implemented and more testing. This task is very time consuming and costly. So we need to go simple to keep the existing class as it is and inherit it to another class where we can add new functionality. This will not impact existing functionality
It means that if we created and used a class it should not get changed/modified. If we need to add anything in it, we should inherit that original class and add the functionality in a derived class.

Liskov Substitution Principle

As per Barbara Liskov, “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”
In this principle, we need to take care of the implementation of the methods in the derived class. If there is a method in Base class and the same is not implemented in derived class then it is the violation of the Liskov Substitution Principle. It is again useful for maintainability, flexibility, and testability.
It means that we must have and implement the logic of ABSTRACT methods and should execute successfully. When I say execute successfully, it means Compile-time and Runtime. There should not be the method which is in the base class and no implementation in the derived class and it should not even throw an exception.

Interface Segregation Principle

As per Wikipedia “In the field of software engineering, the interface-segregation principle(ISP) states that no client should be forced to depend on methods it does not use.”
While working on an application we are dealing with different entities like employees, payments, orders, salary and many more. This principle says that each entity must have separate interfaces so that the functionality of one entity must not mix or interfere in another interface. With this principle, we break the functionality into small pieces or blocks so that they will not be dependent on each other. This segregation really helps a lot while designing and developing the application.
So instead of putting everything, every information in one interface better to create a relative interface. Like IEmployee, IPayment, IAttendance and so on.

Dependency Inversion Principle

AS per Wikipedia “In object-oriented design, a dependency inversion principle is a specific form of decoupling software modules.”
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

There are some Common Criticisms of SOLID,

SOLID Principles Are Vague
SOLID Leads to Complex Code
SOLID Is Too Idealistic
SOLID Is a Marketing Gimmick

Answer to this criticism is SOLID is Principles, not RULES. If you don’t want to implement, don’t do it but then, you will be facing many problems as you grow up with the application. Some are as below.

Singleton
Tight Coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication

Following the SOLID Principle helps us to:

Achieve a reduction in complexity of code. Sometimes it increases complexity, however, it gives other facilities or advantages in the long run.
Increase readability, extensibility, and maintenance
Reduce error and implement reusability. As reusability is the core of programming we must not duplicate the code while developing.
Achieve better testability. This is the most important part of the application as quality is one of the most serious concerns.
Reduce tight coupling which is most important in big applications

--Happy Coding--