SOLID Design Principles in C# by dotnettutorials.net

The SOLID Design principles represent five design principles that basically used to make the software designs more understandable, flexible and maintainable.

The theory of SOLID principles first introduced by Robert C. Martin. In this article, I will discuss the basics of SOLID Design Principles.

​

What is SOLID Principle?

The SOLID Design principles are the design principles that enable us to manage most of the software design problems that generally as a developer we face in our day to day programming. These design principles are provided with some mechanism to make software designs more understandable, flexible and maintainable.

Let’s first discuss the reason behind most of the unsuccessful application.

Developers start designing and developing the applications with their tidy design knowledge and experience. But over the time, the applications might give bugs. Them the developer needs to alter the design for every change request or for any new feature request to include.

After some time we might need to put a lot of effort, even for simple tasks and it might require a full working knowledge of the entire system. But we can’t blame change or new feature requests as they are part of the software development.

We can’t stop them and refuse them either. So who is the culprit here? Obviously, it is the design of the application.

The following are the reasons that cause the damage to the software.

1. Putting more stress on classes by assigning more responsibilities to them. (In the simple word a lot of functionalities we are putting into the class even though they are not related to the class.)
2. Forcing the classes to depend on each other. If classes are dependent on each other (in simple words we can say that they are tightly coupled), then a change in one class will affect the other classes also.
3. Spreading duplicate code in the system/application.

Solution

1. We need to choose the correct architecture (i.e. MVC, 3-tier, Layered, MVP, MVVP and so on) based on the project requirements.
2. As a developer, we need to follow the Design Principles (i.e. SOLID Principles).
3. Again we need to choose correct Design Patterns to build the software based on the project requirements.

SOLID Introduction

1. SOLID Design principles are the design principles that enable us to manage most of the software design problems that generally as a developer we face in our day to day programming.
2. Robert C. Martin compiled SOLID Design principles in the 1990s.
3. The SOLID Design principles represent five design principles that basically used to make the software designs more understandable, flexible and maintainable.
4. The theory of SOLID Design principles was introduced by Robert C. Martin in his 2000 paper Design Principles and Design Patterns, although the SOLID acronym itself was introduced later by Michael Feathers.

SOLID Acronym

1. S: Single Responsibility Principle (SRP)
2. O: Open Closed Principle (OSP)
3. L:  Liskov Substitution Principle (LSP)
4. I:  Interface Segregation Principle (ISP)
5. D: Dependency Inversion Principle (DIP)

Single Responsibility Principle (SRP)

The Solid single responsibility principle states that

“every module or class should have responsibility for a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class”.

Robert C. Martin expresses the principle as, “A class should have only one reason to change”.

Open/Closed Principle (OCP)

The Open Closed Principle states that

“software entities such as classes, modules, functions, etc. should be open for extension, but closed for modification”.

That is, an entity can enable its behavior to be extended without altering its source code.

Liskov Substitution Principle (LSP)

Liskov Substitution Principle is a Substitutability principle which state that, if S is a subtype of T, then objects of type T should be replaced with objects of type S (that means objects in a program should be replaceable with instances of their sub-types) without altering any of the desirable properties of the program (correctness, task performed, etc.).

In simple word, we can say that If a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module

Interface Segregation Principle (ISP)

The interface segregation principle (ISP) states that no class should be forced to implements any methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

That means the main responsibility of ISP is to keep a system more decoupled and thus easier to refactor, change, and redeploy.

Dependency Inversion Principle (DIP)

The dependency inversion principle (DIP) states that

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.

In simple word, we can say that while designing the interaction between a high-level module and a low-level module, the interaction should be thought of as an abstract interaction between them.

Following SOLID Design Principles helps us to 

1. Achieve reduction in complexity of code
2. Increase readability, extensibility and maintenance
3. Reduce error and implement Reusability
4. Achieve Better testability
5. Reduce tight coupling

Following are the Links where I explained each of these principles in a great details with taking some real-time examples.

Single Responsibility Principle

https://dotnettutorials.net/lesson/single-responsibility-principle/

Open Closed Principle

https://dotnettutorials.net/lesson/open-closed-principle/

Liskov Substitution Principle

https://dotnettutorials.net/lesson/liskov-substitution-principle/

Interface Segregation Principle

https://dotnettutorials.net/lesson/interface-segregation-principle/

Dependency Inversion Principle

https://dotnettutorials.net/lesson/dependency-inversion-principle/

​