5.4 Bridging Mode (4.2)

Bridging mode (bridge pattern) is a strategic delegation approach whose main goal is to avoid type explosions .

Description of the problem: if the class client (for example, a client represents a club) will treat people/person in a unified process, and the person class level has (in the person's occupation divides its sub-category) teacher, doctor, lawyer .... In addition, the system also needs to place person according to " Geography " (or by age , income ...) Division, then in the "Wuhan Teacher", "Guangzhou Lawyer" status of the class, its number will be equal to the number of sub-categories of the region and the person (by occupation) the number of sub-class product.

How to control the "Wuhan-teacher" and so on these types of numbers and can also be unified as a person to deal with them?
5.4.1 Alternative Multiple inheritance

Multiple inheritance is prevalent.

There is a is-a relationship between type X and many concepts/types, and its parent types do not necessarily relate to each other, and each parent type describes only one aspect of the narrative x, and x needs (should) inherit multiple parent classes to be the appropriate design. For example, the person (the occupation) and the geographical/region (also can have the age, the income and so on class level), is the independent, unrelated type level, then "the Wuhan Teacher" has the as-a relation with them.

However, Java does not agree with the multi-inheritance of classes, and one possible design scenario is to design the region as an interface based on the person class hierarchy. Provide a set of geographical version numbers for each profession. 10 occupations, from 30 places. It requires 300 classes-- type explosion . To control the type explosion. Can be dominated by person (the principal class), and there will be a type (auxiliary class) region as a member variable of the principal class .

Package delegate.bridge;/** * @author yqj2065 * @version 0.1 */public abstract class person{    protected region where;
   public void Setregion (region where) {//Dependency injection or arbitrary other initialization mode        this.where = where;    }    Introduce oneself public abstract void show according to professional style and dialect    ;}

Package Delegate.bridge;public interface region{public    void Say (String style);

<pre name= "code" class= "Java" >package Delegate.bridge;public class Wher implements region {    @Override public void Say (String style) {   System.out.println (style+ "said:" You are good ");}

Package Delegate.bridge;public class Teacher extends person{@Override public void Show () {String mystyle= "with a taste of chalk ash"; This.where.say (MyStyle);}}

Package Delegate.bridge;import tool. God;public class Client{public static void Test () {person p = (person) god.create ("Teacher");p. Setregion (region) God.create ("region"));    P.show ();}}

This structure allows the number of classes in the system to be greatly reduced. 10 occupations, from 30 places, 10+30 classes are required.

It's worth noting that. (For each occupation, a set of geographical version number) 300 classes. The Say () method of each class has its own any version number, while in the 10+30 class. There are not 300 kinds of say ().

The original complete method body is divided into two stages, and as Person.show (), all the teachers (wherever they are), will reflect their professional characteristics according to the Code of Show (). The Region.say () is then called, and different regions have their own blocks of code.

Therefore, the two-stage code block is combined into a 10*30 method body.
In bridging mode, the outside contact is the person's interface Show (). and Region.say () means the implementation part of show () to some extent .

The role of 5.4.2 bridging

[GoF] A descriptive narrative of the intent of the bridging mode, namely, "decouple anabstraction from its implementation so and the other can varyindependently". ( separating the abstraction from its implementation.) So that they are able to change independently ), I think it is more difficult to understand.

"Abstraction is separated from its implementation." Uncommon expression. , see the section on design patterns. It's tiring, I don't know why it's so awkward.

In accordance with the term system of [introduction to programming], the definition of bridging is as follows:

★ Bridge Mode control type explosion, through auxiliary class to make the method of the principal class polymorphic。

1. Implementation of the show () method is polymorphic

The subject class person has a teacher, a doctor, a lawyer ... Sub-class. Its method is show (), assuming that the say () of the geography/region is not called, each seed class such as teacher--although (each subclass) has different implementations, each of the subclasses is implemented in a fixed way. Teacher is not allowed unless teacher derives whteacher or Gdteacher. Show () has multiple implementations.

In bridging mode, the show () 's method body is called Region.say (), and the implementation of Show () can be configured at execution time (even if it can change its implementation at execution time), according to the actual type of region that points to the object.

The main advantage of bridging mode stems from the advantages of polymorphism.

① principal classes and helper classes can vary independently, and this change refers to the "both can be extended by derived subclasses" that follow the OCP. According to the client code demonstration, person and region sub-class can be arbitrarily combined.

② external contact is the person's interface Show ().

The ③ bridging mode transforms a Cartesian integrable type explosion that can result from multiple independent dimensions into the accumulation of sub-types of auxiliary classes.

Others, thought of the plus.

Last modified: 2014.8.31

5.4 Bridging Mode (4.2)