- Single Responsibility Principle (SRP)
- Open Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
These five design principles used to make software design more understandable, flexible, and maintainable.
1. Single Responsibility Principle (SRP)
Definition: A class should have only one reason to change.
This means that a class should not be loaded with multiple responsibilities and a single responsibility should not be spread across multiple classes or mixed with other responsibilities. And it’s easy to change in class as it has single responsibility. This also reduces number of bugs and improves development speed and most importantly makes developer’s life lot easier.
2. Open Closed Principle (OCP)
This principle suggests that the class should be easily extended but there is no need to change its core implementations. The OCP states that the behaviors of the system can be extended without having to modify its existing implementation. New features should be implemented using the new code, but not by changing existing code. The main benefit of adhering to OCP is that it potentially streamlines code maintenance and reduces the risk of breaking the existing implementation.
3. Liskov Substitution Principle (LSP)
The Liskov Substitution Principle (LSP) states that "you should be able to use any derived class instead of a parent class and have it behave in the same manner without modification".
It ensures that a derived class does not affect the behavior of the parent class.
In other words, that a derived class must be substitutable for its base class.
4. Interface Segregation Principle (ISP)
Definition: No client should be forced to implement methods which it does not use, and the contracts should be broken down to thin ones.
When all the tasks are done by a single class or in other words, one class is used in almost all the application classes then it has become a fat class with overburden. Using ISP, we can create separate interfaces for each operation or requirement rather than having a single class to do the same work.
5. Dependency Inversion Principle (DIP)
This principle says that there should not be a tight coupling among components of software and to avoid that, the components should depend on abstraction. The terms Dependency Injection (DI) and Inversion of Control (IoC) are generally used as interchangeably to express the same design pattern.
Inversion of Control (IoC) is a technique to implement the Dependency Inversion Principle in C#.
Inversion of control can be implemented using either an abstract class or interface. The rule is that the lower level entities should join the contract to a single interface and the higher-level entities will use only entities that are implementing the interface. This technique removes the dependency between the entities.
