English | EN 
SOLID is a mnemonic Object-Oriented Design acronym, introduced by Robert C. Martin, in the year 2000 in Design Principles and Design Patterns, representing coding principles used to produce implementations with reduced tight coupling. The five SOLID coding principles are the Single Responsibility, Open-Closed, Liskov’s Substitution, Interface Segregation, and Dependency Inversion Principles. Other examples of mnemonic Object-Oriented Design acronyms include KISS, GRASP, YAGNI, SOC and DRY. However, they lie outside the scope of this work.
What is Object-Oriented Design (OOD)?
Object-Oriented Design (OOD) is a method used to plan systems of objects and their interaction to solve software problems. Undergoing this process can help to build understandable, flexible, scalable, maintainable, and reusable code.
What is Coupling?
Coupling is the degree of direct knowledge one module has of another. Tight Coupling of modules refers to their high level of interdependence. If two modules are tightly coupled, when one is changed the one may have to as well. Loose Coupling of modules refers to low level of interdependence and high level of independence. If two modules are loosely coupled, the changing of one has little to no impact on the changing of the other. The creation of loosely coupled modules in a system enables the reduction of maintenance and modification costs via flexibility, modularity, scalability, encapsulation, code quality, parallel development, and testability.
Principles
Single Responsibility Principle (SRP)
The Single Responsibility Principle (SRP) states that all classes, modules, and functions should only have one reason to change. Therefore, it should only do one thing, perform one job, or have one responsibility. Along with the benefits of loose coupling mentioned previously, this principle will reduce the complexity of a system. For an example of violating the SRP, imagine a Door. A Door can be opened or closed, therefore, it should only know if it is opened or closed. When this Door class was implemented, methods open() and close() were given to it. This implies the Door knows how to close or open itself. To open or close a Door is the responsibility of the person or thing using it, not the Door. Hence, the SRP has been violated.
Open-Closed Principle (OCP)
The Open-Closed Principle (OCP) states that classes, modules, and functions are open for extension but closed for modification. Abiding by this principle implies the implementation can be extended without modifying existing source code. If new code is made that is not future proof and implies a change for expansion or extension, it will violate this principle. A very common way this principle is violated is through switch statements. If changes are made to the system that force an update to a switch statement, it is not future proof and violates the principle.
Liskov’s Substitution Principle (LSP)
Formulated by Barbara Liskov in 1987, the Liskov’s Substitution Principle or LSP implies that a subclass should be able to replace its superclass without changing the correctness of the program. Adhering to this principle ensures proper hierarchical structure, enhanced reliability and reusability. Overall, this will result in better designs and more efficient and effective testing. For example, take a Bird superclass that requires all birds to fly. Next, take a Penguin subclass of Bird. Penguins cannot fly and, therefore, it cannot substitute its superclass. Hence, LSP has been violated.
Interface Segregation Principle (ISP)
The Interface Segregation Principle, ICP, states that no client should be forced to implement an interface that it does not use, or clients should not be forced to depend on methods they do not use. By applying this principle, creations will be more loosely coupled and get the benefits as such. The above example of the Bird superclass and Penguin subclass also violates the Interface Segregation Principle.
Dependency Inversion Principle (DIP)
The Dependency Inversion Principle states that high-level modules should not depend on low-level modules and, instead, they should depend on abstractions. This principle enforces loose coupling. This can be identified when a class uses a plain class as a global variable instead of that plain class’s interface, even if it does not exist.
Conclusion
The SOLID coding principles can make a world of difference in the quality and cost of an object-oriented system. Whether you are an Architect, Developer, or Engineer, setting the SOLID coding principles as an enforced acceptance criteria of code review or refactoring will ensure that all additions to a system will gain the benefits of loose coupling.
