Image may be NSFW.
Clik here to view.![[Delphi] Design Patterns GoF/Design Patterns GoF/Design Patterns GoF](//www.rssing.com/inc2/img/tinyinf.webp)
[Delphi] Design Patterns GoF/Design Patterns GoF/Design Patterns GoF
Clik here to view.
![[Delphi] Design Patterns GoF/Design Patterns GoF/Design Patterns GoF](http://i.imgur.com/Vst9JUM.jpg)
[Delphi] Design Patterns GoF/Design Patterns GoF/Design Patterns GoF
Today's article marks the beginning of Behavioral design patterns . They are named after proposing and recommending solutions that involve interactions between objects, so that even if there is such interaction, they do not depend heavily on each other, that is, they are loosely coupled. The first of these very easy to understand standards is the Chain of Responsibility . Have you heard? No? Then follow the article! One of the most important assumptions in designing software architecture is to maintain low coupling and high cohesion . The first requirement refers to the elimination of strong dependencies between classes, while the second involves the sole responsibility of each class, responding to the principle called Single Responsibility . A loosely coupled, highly cohesive architecture, therefore, means that the classes are well delimited and each takes on only a unique function in the system. The Chain of Responsibility Design Pattern represents a solution for reducing dependencies between classes. The main purpose is to allow messages (or data) to navigate between different objects within a hierarchy (or chain) until one of them has the ability to assume it, or rather process it, but in one important detail: hierarchy, each object does not know the details of the other.