Bridge Pattern Extra Strokes
Discussion of the long-suffering Bridge template on the hub, revealed many interesting opinions and misconceptions. Let's try to figure it out, revive this template in the eyes of those who are struggling with the wording of the original GoF catalog, and show a few additional touches to those interested in the theme of the templates.
"We are not endowed with the gift of foresight, so those who attribute to the" gang of four "extraordinary abilities will be amazed at the randomness of our development process."
John Vlissides
“When we wrote our book, we really tried to hide something, We wanted to avoid talking about one template being a specialization of another or one template contained in another as its component. We did not want to be distracted, and decided to talk only about templates. This is partly why we did not describe the “abstract class” as a separate template, since it is contained in most templates. I think it was a justified decision when creating the first template directory, but now the situation has changed. People want to know about the connections between the templates, and we need to tell them about it. ”
Ralph Johnson
“GoF-designed design patterns only take into account microarchitecture aspects. It is necessary to choose the right macroarchitecture: leveling, distribution, isolation of functions ... as well as nanoarchitecture: encapsulation, the principle of Liskov substitution (Barbara Liskov). Perhaps, in some places it will be possible to use a certain design pattern, in any case, it is highly unlikely that such a pattern has already been developed and described in any book. ”
Richard Helm
GoF Templates Built on Two Basics
Type: structural
Level: component
Other name: Handle / Body ("Description / body")
Application time : design moment .
Purpose
Separation of a complex component into two independent but interconnected hierarchical structures: functional abstraction and internal implementation.
This makes it easy to change any aspect of the component.
Consider the ideas underlying this template on the example of modeling a component called "Car". Practical value will not be an end in itself.
Step 1. The hierarchy of functionality (first level), in this case it will be enlarged types of cars.
Step 2. The space of sales will reflect the options for representing the car in the bowels of the manufacturer. Pay attention to the explosive increase in static relations in the model and, accordingly, the number of classes to be developed when using inheritance. But at the time of execution, the complexity of the model is linear.
Step 3. Separation of hierarchies, postpone binding until execution. Compare with the circuit element "multi-position switch" or "multiplexer".
Step 4. "Classic" presentation of the template, taking into account these features.
Functionality options: __ 2 ... ..3 .... 3 ... 4 ... ... 4 ... .5
Implementation options: ________ 2 ... ..2 ... .3 ... .3 ... ... 4 ... .4
Classes (inheritance): ______ 4 ... ..6 ... .9 ... 12 ... 16 ... 20
Classes (Bridge template): ______ 4 .... 5 ... .6 ... 7 ... ... 8 ... ..9 The
architecture of the Bridge template allows perform multiplexing of different options for the external representation and internal implementation of the component. The term "multiplexing" means the possibility of association in any combination of external and internal elements, which provides an increase in the range of possible variations of the component.
The separation of the component into two separate concepts, in addition, helps to facilitate the understanding of the purpose of the component and its maintenance. This is explained by the fact that each branch of inheritance is built on the basis of one concept - either abstraction or implementation.
Borders: Functions and implementation are closely related hierarchies located at the same conceptual level, reflecting the structural features of one component. Please note that the implementation is located in the “private / protected” part of the component and reflects the points of variation of the functional concept.
Example: GUI in Java. Public is located in java.awt. *. Private in internal sun packages. *. This protects an important invariant, because there is no point in using, for example, a Mac implementation on Win, and even more so letting external (untrusted) code replace the implementation.
Main hierarchy:The functional hierarchy is central, it knows about variation and uses it (unidirectional association). The implementation hierarchy is subordinate to the needs of the required functions. That is why in GoF it turns out that the DrawRectangle () method is at the functional level, and DrawLine () is at the platform implementation level.
With a bi-directional association, we no longer get a “bridge”, but a “GoF mediator”.
Place among structural patterns: The classic wording indicates the equivalence of changes in both hierarchies. However, one of the "bandits" John Vlissides provides the following list of points of variation.
ADAPTER - object interface;
BRIDGE - implementation of the object;
COMPOSITE - structure and composition of the object;
DECORATOR - obligations of an object without generating a subclass;
FACADE - subsystem interface;
FLYWEIGHT - overhead costs for storage of objects;
PROXY - a way to access the object and / or its location.
Relationship with other templates: If you are trying to move to the “bridge” in the existing model, then in 99% of cases you either aggregate / adapt independent entities or use an intermediary / strategy to encapsulate changes, just do not forget that the original template is a design-time technique (sometimes refactoring), such an initial step, but as soon as your “implementation” leaves the “private” zone and heals on its own it is no longer a “bridge”. The relationship between the levels, the inversion of dependencies is anything but a “bridge” in the sense of GoF.
The "bridge" needs to be "configured" at the time of execution, do not forget perhaps any combination of abstraction - implementation. The logic of “configuration” and observance of invariants is either hidden in the component or given to a component of a higher level (in complex cases there may be an Abstract factory, a dependency container, etc.).
Options such as the separation of the implementation between objects at the time of execution, the use of several implementations at the same time. Described by GoF and can be considered exotic cases in which the "bridge" context for the application of another template.
Define for your component: what is the concept of equality of entities in relation to the Bridge template. Do we need to compare only abstractions or only implementations of objects, or do we need to consider them together?
The problem of the quality of the model: it consists in the fact that often the development of the implementation of the template is based on one or two possible variations. The danger lies in the fact that with the subsequent development of the template, it turns out that some of the elements considered basic, in fact, are specific variations based on abstraction and (or) implementation. This moment was somewhat chaotically stated in the article of the user tac link . But here it is important to remember that the templates do not determine the quality of the domain model, the depth and adequacy of the model substantially depends on the primary tasks of the application, the qualifications of the designer and the opinions of experts in the relevant field.
Empirical (mechanical) criterion - if here and now (at the time of design) youreally need (Functionality options + Implementation options)> 6 i.e. a ratio of the level 3: 3, 3: 4 and higher, then
- break the hierarchies
- what ratio of the code volume turned out 80%: 20%, 50%: 50%, 20% -80%?
- Think if your original concept has broken up into independent entities?
The problem of the original metaphor: the construction metaphor + indistinct wording in the catalog leads to the fact that any horizontal arrow between two independent hierarchies is declared a “bridge”. The “multiplexer” metaphor better reflects the basic implementation technique, and the restriction to the level of one component draws a clear logical boundary with other templates.
I hope the stated “additional touches” made it possible to more clearly show the essence of the template.
References
E. Gamma, R. Helm, R. Johnson, D. Vlissides - Receptions of object-oriented design. Design patterns. GoF Template Directory.
J. Vlissides - Application of design patterns. Extra touches. Here are described templates that are not included in the main catalog Pull / Push, Multicast ... and just interesting sketches of creative torment "gang".
A. Shalloway, J. Trott - Design Patterns. A new approach to object-oriented analysis and design. Reasoning about the slurred wording of the “bridge” and the search for the context of application. Also good reasoning about combining / applying patterns.
S. Stelting, O. Maassen - Application of JAVA templates.Clear positioning of the “bridge” as a component level template. Introduction metaphor telephone switch.
Briefly about GoF templates (Gang of Four - “gang of four”)
"We are not endowed with the gift of foresight, so those who attribute to the" gang of four "extraordinary abilities will be amazed at the randomness of our development process."
John Vlissides
“When we wrote our book, we really tried to hide something, We wanted to avoid talking about one template being a specialization of another or one template contained in another as its component. We did not want to be distracted, and decided to talk only about templates. This is partly why we did not describe the “abstract class” as a separate template, since it is contained in most templates. I think it was a justified decision when creating the first template directory, but now the situation has changed. People want to know about the connections between the templates, and we need to tell them about it. ”
Ralph Johnson
“GoF-designed design patterns only take into account microarchitecture aspects. It is necessary to choose the right macroarchitecture: leveling, distribution, isolation of functions ... as well as nanoarchitecture: encapsulation, the principle of Liskov substitution (Barbara Liskov). Perhaps, in some places it will be possible to use a certain design pattern, in any case, it is highly unlikely that such a pattern has already been developed and described in any book. ”
Richard Helm
GoF Templates Built on Two Basics
- Find change points and encapsulate them.
- Composition of objects at runtime is preferable to inheritance.
- Reproducibility of reception in at least 3 independent implementations. If possible, regardless of the programming language.
- Consent of the group with the name (metaphor) and the basic structure of the template.
Bridge Template
Type: structural
Level: component
Other name: Handle / Body ("Description / body")
Application time : design moment .
Purpose
Separation of a complex component into two independent but interconnected hierarchical structures: functional abstraction and internal implementation.
This makes it easy to change any aspect of the component.
Demonstration
Consider the ideas underlying this template on the example of modeling a component called "Car". Practical value will not be an end in itself.
Step 1. The hierarchy of functionality (first level), in this case it will be enlarged types of cars.
Step 2. The space of sales will reflect the options for representing the car in the bowels of the manufacturer. Pay attention to the explosive increase in static relations in the model and, accordingly, the number of classes to be developed when using inheritance. But at the time of execution, the complexity of the model is linear.
Step 3. Separation of hierarchies, postpone binding until execution. Compare with the circuit element "multi-position switch" or "multiplexer".
Step 4. "Classic" presentation of the template, taking into account these features.
Comparison with inheritance
Functionality options: __ 2 ... ..3 .... 3 ... 4 ... ... 4 ... .5
Implementation options: ________ 2 ... ..2 ... .3 ... .3 ... ... 4 ... .4
Classes (inheritance): ______ 4 ... ..6 ... .9 ... 12 ... 16 ... 20
Classes (Bridge template): ______ 4 .... 5 ... .6 ... 7 ... ... 8 ... ..9 The
architecture of the Bridge template allows perform multiplexing of different options for the external representation and internal implementation of the component. The term "multiplexing" means the possibility of association in any combination of external and internal elements, which provides an increase in the range of possible variations of the component.
The separation of the component into two separate concepts, in addition, helps to facilitate the understanding of the purpose of the component and its maintenance. This is explained by the fact that each branch of inheritance is built on the basis of one concept - either abstraction or implementation.
Important points
Borders: Functions and implementation are closely related hierarchies located at the same conceptual level, reflecting the structural features of one component. Please note that the implementation is located in the “private / protected” part of the component and reflects the points of variation of the functional concept.
Example: GUI in Java. Public is located in java.awt. *. Private in internal sun packages. *. This protects an important invariant, because there is no point in using, for example, a Mac implementation on Win, and even more so letting external (untrusted) code replace the implementation.
Main hierarchy:The functional hierarchy is central, it knows about variation and uses it (unidirectional association). The implementation hierarchy is subordinate to the needs of the required functions. That is why in GoF it turns out that the DrawRectangle () method is at the functional level, and DrawLine () is at the platform implementation level.
With a bi-directional association, we no longer get a “bridge”, but a “GoF mediator”.
Place among structural patterns: The classic wording indicates the equivalence of changes in both hierarchies. However, one of the "bandits" John Vlissides provides the following list of points of variation.
ADAPTER - object interface;
BRIDGE - implementation of the object;
COMPOSITE - structure and composition of the object;
DECORATOR - obligations of an object without generating a subclass;
FACADE - subsystem interface;
FLYWEIGHT - overhead costs for storage of objects;
PROXY - a way to access the object and / or its location.
Relationship with other templates: If you are trying to move to the “bridge” in the existing model, then in 99% of cases you either aggregate / adapt independent entities or use an intermediary / strategy to encapsulate changes, just do not forget that the original template is a design-time technique (sometimes refactoring), such an initial step, but as soon as your “implementation” leaves the “private” zone and heals on its own it is no longer a “bridge”. The relationship between the levels, the inversion of dependencies is anything but a “bridge” in the sense of GoF.
The "bridge" needs to be "configured" at the time of execution, do not forget perhaps any combination of abstraction - implementation. The logic of “configuration” and observance of invariants is either hidden in the component or given to a component of a higher level (in complex cases there may be an Abstract factory, a dependency container, etc.).
Options such as the separation of the implementation between objects at the time of execution, the use of several implementations at the same time. Described by GoF and can be considered exotic cases in which the "bridge" context for the application of another template.
Define for your component: what is the concept of equality of entities in relation to the Bridge template. Do we need to compare only abstractions or only implementations of objects, or do we need to consider them together?
The problem of the quality of the model: it consists in the fact that often the development of the implementation of the template is based on one or two possible variations. The danger lies in the fact that with the subsequent development of the template, it turns out that some of the elements considered basic, in fact, are specific variations based on abstraction and (or) implementation. This moment was somewhat chaotically stated in the article of the user tac link . But here it is important to remember that the templates do not determine the quality of the domain model, the depth and adequacy of the model substantially depends on the primary tasks of the application, the qualifications of the designer and the opinions of experts in the relevant field.
Empirical (mechanical) criterion - if here and now (at the time of design) youreally need (Functionality options + Implementation options)> 6 i.e. a ratio of the level 3: 3, 3: 4 and higher, then
- break the hierarchies
- what ratio of the code volume turned out 80%: 20%, 50%: 50%, 20% -80%?
- Think if your original concept has broken up into independent entities?
The problem of the original metaphor: the construction metaphor + indistinct wording in the catalog leads to the fact that any horizontal arrow between two independent hierarchies is declared a “bridge”. The “multiplexer” metaphor better reflects the basic implementation technique, and the restriction to the level of one component draws a clear logical boundary with other templates.
I hope the stated “additional touches” made it possible to more clearly show the essence of the template.
References
E. Gamma, R. Helm, R. Johnson, D. Vlissides - Receptions of object-oriented design. Design patterns. GoF Template Directory.
J. Vlissides - Application of design patterns. Extra touches. Here are described templates that are not included in the main catalog Pull / Push, Multicast ... and just interesting sketches of creative torment "gang".
A. Shalloway, J. Trott - Design Patterns. A new approach to object-oriented analysis and design. Reasoning about the slurred wording of the “bridge” and the search for the context of application. Also good reasoning about combining / applying patterns.
S. Stelting, O. Maassen - Application of JAVA templates.Clear positioning of the “bridge” as a component level template. Introduction metaphor telephone switch.