Shulou(Shulou.com)06/01 Report--

Today Xiaobian to share with you how to use typescript to achieve Bridge mode related knowledge points, detailed content, clear logic, I believe most people still know too much about this knowledge, so share this article for everyone to refer to, I hope you read this article after some harvest, let's learn about it together.

Bridge (bridge mode)

Bridge (bridge mode) belongs to structural mode, which is a solution to flexible extension after inheritance.

Intention: Separate the abstract part from its implementation part so that they can change independently.

Bridging patterns are difficult to understand, but I'll go back to thinking about them step by step so you can see how they've been refined step by step.

examples given

If you don't understand the intention above, it doesn't matter. Design patterns need to be used in daily work. Combining examples can deepen your understanding. Below I have prepared three examples to let you experience what scenarios will use this design pattern.

Automobile production line transformed into new energy production line

There are great similarities between the production process of gasoline vehicles and new energy vehicles, so can the gasoline vehicle production line be quickly transformed into a new energy vehicle production line?

If the gasoline vehicle production line does not decouple the interior and only separates the parts of the gasoline vehicle, it is useless for the new energy vehicle production line, but if the gasoline vehicle production line provides a lower level of capability, such as adding tires and installing steering wheels, then these steps can be shared by both gasoline vehicles and new energy vehicles.

When designing the gasoline vehicle production line, the production process is decoupled from the gasoline vehicle, so that it can be quickly applied to the production of new energy vehicles, which is an application of the bridge mode.

Derivation of Window class

Suppose there is a Window class whose underlying implementation is different in different operating systems. Suppose that for operating systems A and B, there are AWindow and BWindow inherited from Window respectively. Now to make a new function ManageWindow (Manager Window), we must generate AManageWindow and BManageWindow for operating systems A and B respectively, which is obviously not easy to expand.

Whether we add support for the C operating system or add support for an IconWindow, the number of classes will increase exponentially, because our AMangeWindow and BMangeWindow have two or more independent dimensions at the same time, which makes the code redundant when adding dimensions.

Materials suitable for multiple platforms

When doing front-end building platforms, some materials (components) often appear because the API of a certain building platform is solidified, so they cannot be migrated to another building platform. If you want to migrate, you need to write different components for different platforms, and most of these components have the same UI logic, which makes a lot of code redundant. If you are compatible with a new building platform, or create a new component for the existing 10 building platforms, The workload is several times that of writing a component.

intended to be interpreted

Intention: Separate the abstract part from its implementation part so that they can change independently.

The "abstract" part is separated from the "implementation" part, which looks a lot like interfaces and implementations. Indeed, if "abstract" refers to an interface and "implementation" refers to a class, this is simply the class MyWindow implements Window class implementation process.

But the second half of the sentence,"make them independently variable," makes it difficult to connect with the first half. It is understandable to say that "abstract" is unchanged and "implementation" can change at will, but the reverse is difficult to explain.

In fact, in the bridge pattern, abstraction refers to an interface (Abstraction), and implementation refers to an interface (Implementor), where Implementor does not directly implement the interface defined by Abstraction, but provides a lower level method, so that Abstraction can encapsulate its own interface implementation based on them.

In this way, the interface of Abstraction can be changed at will. After all, the combination of functions provided by Implementor is called. As long as the functions provided by Implementor are comprehensive, Implementor can remain unchanged. Correspondingly, the implementation of Implementor can also be changed at will. As long as the underlying functions provided are unchanged, it does not affect the use of Abstraction.

The above three examples are all like this. We should separate the standard of gasoline car production line from the standard of general automobile production line, isolate the specific function window from the basic GUI capability of adapting different operating systems, and isolate the component function from the platform function. Only by separating the abstract part from the implementation part can we satisfy more scenarios through combination.

structure diagram

Abstraction: Defines the interface of an abstract class.

RefinedAbstraction: Extended Abstraction.

Implementor: Defines the interface of the implementation class, which may be inconsistent with the Abstraction interface.

ConcreteImplementor: Implement the Implementor interface and define its concrete implementation.

Abstract part is Abstraction, implementation part is Implementor, in this structure diagram, they are separate, can be independently changed, bridge mode, that is, imp this bridge, through Implementor to achieve Abstraction interface, even if the bridge is on, this combination of bridge than ordinary class implementation more flexible, more extensible.

code examples

For the full version of the bridge pattern, Implementor can have multiple implementations, Abstraction does not need to care about which implementation is used, but is encapsulated by abstract factory. Here's a simple example.

The following example is written using typescript.

class Window {

private windowImp: WindowImp

public drawBox() {

//Create a 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)

}

}

//Windows are easy to expand.

class SuperWindow extends Window {

public drawIcon {

//Draw lines by custom

this.windowImp.drawLine(0, 5)

this.windowImp.drawLine(3, 9)

}

}

The essence of the bridge pattern can be understood from the above example:

Window's ability is drawBox. Is it easy to extend drawIcon by inheriting Window? The default is no good because Windows does not provide this capability. After analysis, we can see that drawing is a basic ability and should not be coupled with Window code, so we put the basic ability into windowImp, so drawIcon can also draw lines with its basic ability.

drawbacks

Don't be overly abstract, the bridge pattern is to make the responsibilities of the class more simple and easier to maintain, but if it is only a small project, the bridge pattern will increase the complexity of the architectural design, and the incorrect module splitting will force the original associated logic to decouple, which will lead to bigger problems in the future.

In addition, bridge patterns are also divided into simple and complex patterns. If there is only one implementation scenario, don't over-encapsulate it with abstract factories.

The above is "how to use typescript to achieve Bridge mode" all the content of this article, thank you for reading! I believe everyone has a great harvest after reading this article. Xiaobian will update different knowledge for everyone every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.