SOLID Design Principles
SOLID design principles are some set of best practices for object oriented programming. SOLID stands for
- Single responsibility principle (SRP)
- Open-Closed principle (OCP)
- Liskov substitution principle (LSP)
- Interface segregation principle (ISP)
- Dependency inversion principle (DIP)
Single responsibility principle
“There should never be more than one reason for a class to change”.
This means every object should have single focus of responsibility. This can be applied in different levels.
- A method should carry out one thing only
- A domain object should only represent one isolated object within business domain
- Presentation layer should be only responsible for presenting data
Purpose of implementing this principle is to get High Cohesive & Low Couples code which is easily testable and maintainable.
- Cohesion: how strongly related and focused the various responsibilities of a module are
- Coupling: the degree to which each program module relies on each one of the other modules
Open-Closed principle
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”
Software that works should when possible not be changed when your application is extended with new functionality.Instead it should be possible to extend the existing software with new functionality without any modification to the current codebase and without adding duplicate code or duplicate functionality.
To state the open closes principle very straightforward way you can say :
- You should design modules that never change.
- When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works.
Liskov substitution principle
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”.
you can find good code example here.
Interface segregation principle
“Clients should not be forced to implement interfaces they don't use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module”.
ex:-
I here rather having all the methods for the inside in one Interface we have divide the read operation in to one single interface. So any class need only reading operation can implement. So it does not need to implement methods which are not relevant it’s need.
Dependency inversion principle
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
The goal of the dependency inversion principle is to decouple application glue code from application logic. Reusing low-level components (application logic) becomes easier and maintainability is increased. This is facilitated by the separation of high-level components and low-level components into separate packages/libraries, where interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component's package. The implementation of the high-level component's interface by the low level component requires that the low-level component package depend upon the high-level component for compilation, thus inverting the conventional dependency relationship. Various patterns such as Plugin, Service Locator, or Dependency Injection are then employed to facilitate the run-time provisioning of the chosen low-level component implementation to the high-level component.
you can find good document here.
Happy Coding !!!!
Comments
Post a Comment