SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. The object-oriented analysis and design explain the system interaction and design the software effectively. The design pattern explains the set of best practices provided by the industry for a long time.
The SOLD design principles explained in the following
- Single Responsibility principle
- Open closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
Single Responsibility principle
A class should have only one reason to change.
The single responsibility principle is an object-oriented design principle that expects every module or class should have a single responsibility and encapsulate by the module or class. If any other object requires, it should encapsulate by another class and call using as the container. The software module or microservice follows the same and should not allow changing for different reasons.
For example, the classroom contains a student, teacher, whiteboard, books, tables, and pen. The software design must contain appropriate roles and responsibilities for each object. The classroom should not control the student directly and can contain student class. If classroom requests, it encapsulated by student class.
Open Closed principle
Software entities like classes, modules and functions should be open for extension but closed for modifications.
The open-closed principle that expects the class or module should be open for extension. The class can be extended by one or more interfaces. The software system interacts through interfaces and implementation uses containment for communication. If the class wants to extend other futures, it implements another interface and Implements the methods. The design pattern helps to close the state. The client can not update the state directly and encapsulate through methods.
Derived types must be completely substitutable for their base types.
The Liskov-substitution principle expects the derived/implemented classes should be substitutable with the base class or interface. If the base class has common methods and call uniformly with all the callers. The implementation may be different based on the requirement. The java interface uses to assign the implementation. Example, List<String> listEmployee = new ArrayList<>(). The List interface contains common contracts and implemented with a different derived class. If the programmer willing to change the implementation, the programmer can change only the definition.
Interface segregation principle
Clients should not be forced to depend upon interfaces that they do not use.
Interface segregation principle splits interfaces that are very large into smaller and more specific ones. The clients will only have to know about the methods that are of interest to them. Example The user defines an interface for the bird. All the birds may not fly and may segregate the interface into Birds and FlyingBirds. The birds may be marker interface and do not have any methods. The FlyingBirds contains the fly() method. The designer should define the interface design properly for decoupling the systems or modules.
Dependency inversion principle
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.
A dependency inversion principle is a specific form of decoupling software modules. The higher-level module and lower-level module should always interact though the contact interfaces. If any class or module interact with each other, it should not call the method directly. The high- and low-level components interact through the interface.