Patterns to implement SOLID principles

Question

I\'m doing a presentation of SOLID design principles and I\'m trying to connect the Single Responsibility Principle and the Open-Closed principle to design patterns.

Cur

Answer 1

The SOLID principles are more attributes of a good OO language and framework than anything else. They don't handily translate into design patterns. Rather, they influence good vs. bad in a design pattern.

Generally, all of the SOLID principles show up in each design pattern somewhere. If all the SOLID principles don't show up, you have a way to improve on the design pattern.

Single Responsibility is really Encapsulation plus some aspects of inheritance and polymorphism. Single Responsibility is more of a basic principle or tenet of how to decompose a problem into cooperating objects and define the classes of those objects. All design patterns should illustrate this.

Similarly, Open/Closed is a language feature, usually implemented via inheritance. But it can be done via monkeypatching. All design patterns should illustrate this.

Liskov Substitution, also, is usually a language feature. We often implement this with well-design polymorphic classes. Some folks argue that duck-typing breaks this principle, other say that duck-typing manifests it. There are numerous design patterns which rely on Liskov Substitution. Anything with polymorphism will exhibit Liskov Substitution.

Interface Segregation can be a language feature. Java has it. Python -- by most accounts -- doesn't do this. However, you'll note that many Python projects try to formalize their interface definitions with superclasses and unit tests.

Dependency Inversion (depend on abstractions) is often a language feature. Not many design patterns insist on this. However, many of us like to use the abstractions in the Java Collections library so that we can use Liskov Substitution among the concrete classes.