Golang Design Patterns – Bridge. Separation of abstraction and implementation

Bridge is a more confusing design pattern than previous series designs. According to the original Gang of Four book: ” decouple an abstraction from its implementation so that the two can vary independently “, which is quite different from always trying to include abstraction in the design patterns we know. Let’s take a closer look at this design.

I. Bridge – Structural Pattern

To be a bit more explicit, Bridge separates an abstraction (which most other design patterns bring about) or an object from its implementations. This way we can make an object do whatever we want, or change an abstract object but still reuse its implementations.

II. What does Bridge bring to developers?

The most obvious is the flexibility that this design pattern brings to objects and structs that are regularly updated and added. There is also no binding when changing the code between the two sides of the object definition and implementation.

III. Practical examples

Take a practical example with the case that we need to deploy a print management system, including 2 main objects: a computer and a printer. By default with the computer we have 2 objects MacOS and Window, with the printer is Canon, we can deploy the following objects: MacOSCanon and WindowCanon. Each object has a Print method, which prints information about the computer and printer currently in use.

In case of adding an Epson printer type, we will need to add 2 MacOSEpson and WindowEpson objects, with all the methods that MacOSCanon or WindowCanon can do.

As you can see, given the number of X computers and Y printers, the objects we have to deploy are X*Y , a lot, right.

This is where Bridge jumps in to tackle the problem. As I said at the beginning of the article, the ways to remember the essence of Bridge are: separate abstraction and implementation . Applied to the example, then the computer is considered abstraction , and the printer is implementation . These two objects communicate through Bridge , where abstractions (computers) contain references to implementations (printers).

A pretty funny example of a very memorable Bridge that I collected from Guru ‘s site:

IV. Implementation

Printer objects always have a Print method, we need to define it first, through the Printer interface

Next, define the corresponding HP and Epson Printers based on the Printer interface as follows:

Done with the Implementation part definition, now on to the Abstraction section definition, starting with Computer :

As I said above, the abstraction will contain a reference to the printer, so computers always contain the printer instance, the SetPrinter method as a flexible way for us to change the printer that the computer object uses. :

Run the above program:

With results:

I have given an example at the most basic level for everyone to have the most intuitive view of the Bridge design pattern. We won’t have to deal with deleting one of the printer or computer objects, or face repetitive definition work when adding a type of computer or printer, for example.

V. Conclusion

Not always having problems like above we always use the Bridge pattern to solve the problem, everyone can use the Factory pattern that we mentioned, for example, or…don’t use any design pattern. any plan if the problem is not too complex in terms of the number of objects. It’s all up to you

Thank you for viewing the article.

BECAUSE. References

• Go Design Patterns (Mario Castro Contreras)
• Guru