20 April 2024
The SOLID design principles are a set of guidelines meant to improve software development and maintenance, making code more modular, scalable, and flexible. These principles were first developed by Robert C. Martin (Uncle Bob) in the essay Design Principles and Design Patterns and are widely used in object-oriented design. They were letter coined the SOLID design principles by Michael Feathers. Each letter in "SOLID" stands for a different principle:
These principles help in creating more maintainable, scalable, and robust systems, especially as applications grow in size and complexity. They are foundational to many modern software engineering approaches, including agile and adaptive software development.
A class should have only one reason to change, meaning it should have only one job or responsibility. This principle aims to reduce the complexity of classes and make them easier to manage by assigning a single responsibility to each class.
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This principle suggests that you should be able to add new functionality to an existing class without altering its existing code, typically by using interfaces or abstract classes.
Objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. This principle promotes the correctness of inheriting classes, ensuring that they behave in accordance with the expectations set by their base class.
No client should be forced to depend on methods it does not use. This principle encourages the creation of specific interfaces rather than one general-purpose interface, reducing the side effects of changes in unrelated methods and promoting more focused class implementations.
High-level modules should not depend on low-level modules; both should depend on abstractions. Moreover, abstractions should not depend on details; details should depend on abstractions. This principle guides the structure of dependencies within the system, advocating that both high-level business rules and low-level implementation details should rely on the same abstract interfaces.
A class should have only one reason to change, meaning it should have only one job or responsibility. This principle aims to reduce the complexity of classes and make them easier to manage by assigning a single responsibility to each class.
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This principle suggests that you should be able to add new functionality to an existing class without altering its existing code, typically by using interfaces or abstract classes.
Objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. This principle promotes the correctness of inheriting classes, ensuring that they behave in accordance with the expectations set by their base class.
No client should be forced to depend on methods it does not use. This principle encourages the creation of specific interfaces rather than one general-purpose interface, reducing the side effects of changes in unrelated methods and promoting more focused class implementations.
High-level modules should not depend on low-level modules; both should depend on abstractions. Moreover, abstractions should not depend on details; details should depend on abstractions. This principle guides the structure of dependencies within the system, advocating that both high-level business rules and low-level implementation details should rely on the same abstract interfaces.
