Bridge (Bridge mode)
Bridge mode belongs to structural mode, which is a flexible extension solution after inheritance.
Intent: Separate the abstract part from its implementation so that they can vary independently.
Bridge mode is difficult to understand, I will restore the thinking of this design mode step by step, let you experience how this design mode is refined step by step.
For example,
If you don’t understand the above description, it doesn’t matter. Design patterns need to be used in daily work. Examples will help you understand better.
The automobile production line was transformed into a new energy production line
The production process of gasoline cars and new energy vehicles is very similar, so can the gasoline car production line be quickly transformed into the production line of new energy vehicles?
If petrol car production line decoupling, the internal implementation is not only the production of gasoline vehicles out of the parts of the independent, the new energy vehicle production line is useless, but if the petrol car production line to provide more at the bottom of the ability, like tires, equipped with the steering wheel, so these steps can also be gasoline vehicles and new energy vehicles Shared.
In the design of gasoline car production line, the production process and gasoline car decoupled, so that it can be quickly used in the production of new energy vehicles, this is a bridge mode of application.
A descendant of the Window class
Suppose we have AWindow class, the underlying implementation of which varies from operating system to operating system. Suppose we have AWindow and BWindow inherited from Windows for operating system A and B, and now we’re going to do A new function, ManageWindow. We need to generate AManageWindow and BManageWindow for operating systems A and B, which is obviously not easy to expand.
No matter we add support for C operating system or add support for IconWindow, the number of classes will be doubled, because the AMangeWindow and BMangeWindow we made have two or more independent dimensions at the same time, which makes the code redundant when adding dimensions.
Suitable for multiple building platform materials
Do front-end platform structures, often appear some materials (components) for curing a platform API, so can’t migrate to another platform, if you want to migrate, you need to write a different components for different platforms, and most of these components UI logic is the same, which produces a large number of redundant code, Compatibility with a new scaffolding, or creating a new component for 10 existing scaffolding platforms, is many times as much work as writing a single component.
Intention to explain
Intent: Separate the abstract part from its implementation so that they can vary independently.
The “abstract” part is separated from the “implementation” part, which looks a lot like interface and implementation. Indeed, if “abstract” means an Interface and “implemented” means a Class, this is simply Class MyWindow implements Window.
But the second part of the sentence, “make them independent of change,” makes it hard to relate to the first part of the sentence. It makes sense to say that abstraction remains the same and implementation can be changed at will, but the reverse is hard to explain.
In bridge mode, the Abstraction is an interface, and the implementation is also an interface that does not directly implement the Abstraction but provides a lower-level method, Enable Abstraction to encapsulate its own interface implementation based on them.
This way, the Abstraction can be changed at will. After all, it is called a combination of functions provided by the Implementor, and the Implementor can remain the same as long as the functionality provided by the Implementor is comprehensive. Accordingly, the implementation of the Implementor can also change at will, without affecting the use of Abstraction as long as the underlying function provided remains unchanged.
The three examples above are in this way, we should put gasoline car production line of separation and gm production line standard, put the specific window function and adaptation GUI ability to isolate the basis of different operating systems, components and platform isolation, only do the abstract parts and the implementation of segregation, can through combination meet more scenes.
chart
- Abstraction: Interface that defines the abstract class.
- RefinedAbstraction: Expanded Abstraction.
- Implementor: Defines an interface for the implementation class that can be different from the Abstraction interface.
- ConcreteImplementor: Implements the Implementor and defines its concrete implementation.
The Abstraction is the Abstraction, the implementation is the Implementor, in this structure, they are separate, they can change independently, the bridge is the IMP bridge, the Abstraction is the Implementor, Even if it does, this combination of bridging is more flexible and extensible than a normal class implementation.
The code example
For the full bridge pattern, the Implementor can have multiple implementations, which are abstracted in a factory way, regardless of which implementation is used. Here’s an example of a simpler version.
The following example is written in typescript.
class Window {
private windowImp: WindowImp
public drawBox() {
// Generate box by drawing a line
this.windowImp.drawLine(0.1)
this.windowImp.drawLine(1.1)
this.windowImp.drawLine(1.0)
this.windowImp.drawLine(0.0)
}
}
// Extending Windows is very easy
class SuperWindow extends Window {
public drawIcon {
// Use custom drawing
this.windowImp.drawLine(0.5)
this.windowImp.drawLine(3.9)
}
}
Copy the codeThe essence of the bridge pattern can be understood from the above example:
Window’s ability is drawBox. Is it easy to extend the drawIcon from Window? The default does not work because Windows does not provide this capability. As you can see from our analysis, underline is a basic ability that should not be coupled to Window code, so we put the basic ability in windowImp so that drawIcon can also use its basic ability to draw lines.
disadvantages
Don’t be overly abstract. The bridge pattern is intended to make classes more accountable and easier to maintain. However, if you are working on a small project, the bridge pattern can increase the complexity of architectural design, and improper module splitting, forcing decoupling of originally associated logic, can lead to bigger problems in the future.
In addition, bridge patterns can be divided into simple and complex patterns, so don’t over-encapsulate scenarios with abstract factories if there is only one implementation.
conclusion
The bridge mode allows us to re-examine whether the design of classes is reasonable. The irrelevant or independent dimensions of classes are removed and used in the bridge mode. In this way, each class will have more cohesive functions, less and clearer code, stronger combination ability and easier to expand.
Here’s a simple explanation:
The discussion address is: Intensive reading design Pattern-Bridge Pattern · Issue #280 · DT-fe /weekly
If you’d like to participate in the discussion, pleaseClick here to, with a new theme every week, released on weekends or Mondays. Front end Intensive Reading – Helps you filter the right content.
Pay attention to the front end of intensive reading wechat public account
Copyright Notice: Freely reproduced – Non-commercial – Non-derivative – Remain signed (Creative Commons 3.0 License)