SOLID
The SOLID principles ensure that OOP applications are readable, testable, scalable, and maintainable.
The SOLID concepts are:
Single-responsibility principle:
- “There should never be more than one reason for a class to change.” In other words, every class should have only one responsibility.
- If a Class has many responsibilities, it increases the possibility of bugs because making changes to one of its responsibilities, could affect the other ones without you knowing.
Open–closed principle:
- “Software entities … should be open for extension, but closed for modification.”
- This principle aims to extend a Class’s behaviour without changing the existing behaviour of that Class. This is to avoid causing bugs wherever the Class is being used.
Liskov substitution principle:
“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it”.
When a child Class cannot perform the same actions as its parent Class, this can cause bugs.
If you have a Class and create another Class from it, it becomes a parent and the new Class becomes a child. The child Class should be able to do everything the parent Class can do. This process is called Inheritance.
The child Class should be able to process the same requests and deliver the same result as the parent Class or it could deliver a result that is of the same type.
The picture shows that the parent Class delivers Coffee(it could be any type of coffee). It is acceptable for the child Class to deliver Cappucino because it is a specific type of Coffee, but it is NOT acceptable to deliver Water.
This principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.
Interface segregation principle:
- “Many client-specific interfaces are better than one general-purpose interface.”
- Clients should not be forced to depend on methods that they do not use.
- This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.
Dependency inversion principle:
- “Depend upon abstractions, [not] concretions.”
- High-level modules should not depend on low-level modules. Both should depend on the abstraction.
- Abstractions should not depend on details. Details should depend on abstractions.
GRASP
Information expert
Creator
Controller
Indirection
Low coupling
High cohesion
Polymorphism
Protected variations
Pure fabrication
solid different from oop pillars? solid vs grasp?
https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o https://en.wikipedia.org/wiki/GRASP_(object-oriented_design) https://stackoverflow.com/questions/4270912/what-is-the-difference-between-gof-and-grasp-design-patterns
Law of Demeter
- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
- Each unit should only talk to its friends; don’t talk to strangers.
- Only talk to your immediate friends. https://en.wikipedia.org/wiki/Law_of_Demeter#History
More
FAQs
How SOLID is different from OOP Pillars (Abstraction, Encapsulation, Inheritance, Polymorphism)?
Encapsulation, Abstraction, Inheritance and Polymorphism are basic OOP concepts, languages or concepts which don’t support Encapsulation, Abstraction, Inheritance and Polymorphism are not object oriented. If you do something object oriented you can always apply these OO basics, because they are available. One doesn’t call such things principles.
Whereas SOLID is optional. When developing an OO design you should strive to be SOLID, by applying the underlying basics. Solid only determines how “good” your design is, not if it is object oriented or not.
Who introduced SOLID?
Five of Robert C Martin’s principles have become known collectively as the SOLID principles. Though he invented most of the principles he promotes, the Liskov substitution principle was invented by Barbara Liskov, while the open–closed principle was invented by Bertrand Meyer.