In Java, SOLID principles are an object-oriented approach to designing software structures. It was created by Robert C. Martin (also known as Uncle Bob).
These five principles have transformed the field of object-oriented programming, as well as the way software is written.
It also guarantees that the software is modular, simple to comprehend, debug, and refactor.
SOLID is a systematic design technique that makes your software modular and easy to maintain, understand, debug, and refactor.
Maintaining and developing software requires less time and effort when SOLID principles are followed.
SOLID keeps your code from becoming inflexible and fragile, allowing you to design long-lasting software.
SOLID stands for five other class design principles:
Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle.
1. Single Responsibility Principle (SRP):
According to the single responsibility concept, each Java class must perform a single functionality. The implementation of various functionalities in a single class mashes up the code, and any changes required may damage the entire class. The code is straightforward to maintain and specific.
It means that a class should have only one reason to change, which is equivalent to having only one job or obligation. In other words, each class should be responsible for a specific system component or operation.
2. Open-Closed Principle (OCP):
Software entities (such as classes, modules, and functions) should be extensible but not modifiable. Furthermore, software components should allow for extension but not alteration.
The application or module consists of methods, functions, variables, and so on. The open-closed principle emphasizes that a module should be extensible but not modifiable in order to satisfy new requirements. The extension lets us add new functionality to the module.
3. Liskov Substitution Principle (LSP):
Barbara Liskov introduced the Liskov Substitution Principle (LSP). It applies to inheritance in such a way that the derived classes are totally interchangeable with their source classes. In other words, if class A is a subtype of class B, we should be able to substitute B with A without affecting the program's behavior.
It broadens the open-close principle and focuses on the behavior of a superclass and its subtypes. We should build the classes to preserve the property unless there is a compelling reason to do otherwise.
Superclass objects should be replaceable with subclass objects without impacting program correctness.
4. Interface Segregation Principle (ISP):
Clients should not be made to rely on interfaces that they do not use. Rather than one large interface, numerous tiny interfaces are recommended.
The principle states that larger interfaces divide into smaller ones. Because the implementation classes only call the methods that are required. We should not compel the client to utilize methods they do not choose to use.
The interface segregation principle aims to achieve the same goal as the single responsibility principle.
5. Dependency Inversion Principle (DIP):
High-level modules should not rely on lower-level modules. Both should be based on abstractions (for instance, interfaces). Details should be based on abstractions.
The idea requires that we employ abstraction (abstract classes and interfaces) rather than specific implementations. High-level modules should not depend on low-level modules, but rather on the abstraction. Because abstraction is independent of detail, whereas detail is dependent on abstraction. It decouples the software.
Comments