Bridge patterns are not commonly used, and the concept of bridge patterns is abstract. The bridging pattern is generally used when there are multiple classifications. If the implementation system is likely to have multiple classifications, each of which is subject to change, isolate these classifications and allow them to change independently, reducing the coupling between them.

In this paper, a UML class diagram link is: www.processon.com/view/link/6…

This article is linked to: github.com/shidawuhen/…

Definition 1.

1.1 Bridge Mode

Bridge pattern: Separate the abstract part from its implementation part so that they can all change independently.

UML class diagram:

1.2 analysis

Looking at the bridge pattern definition and UML class diagram alone, this pattern is difficult to understand, and much easier to understand when placed in a given scenario. Here’s an example from The Big Talk Design Pattern:

Abstraction is mobile phone category, RefinedAbstractionA refers to xiaomi phone, RefinedAbstractionB refers to huawei phone.

I am a mobile phone software provider, and Implementor is mobile phone software, and ConcreteImplementorA is game software. Theoretically, ConcreteImplementorA should have two subclasses, namely xiaomi mobile phone game and Huawei mobile phone game. ConcretelmplementorB is an address book software, also has two subclasses, namely Mi phone address book and Huawei phone address book.

If you look at this design, you may think it is ordinary, but when it comes to real design, many students may not separate the two categories. They may design according to the brand, such as the mobile phone brand and the corresponding application under the mobile phone brand, or design according to the mobile phone software and the corresponding mobile phone under the software. Something like this

The second design is certainly not as good as the first, but what’s so good about it?

  1. Classification is more reasonable. The first kind of phone is a phone and software is software, which is very clear, but the second kind of phone and software are mixed together, which is very confusing.

  2. Composition is better than inheritance. The first use combination makes the relationship between the phone and the software so weak that the two can vary independently. The second way to use inheritance, software inheritance from the phone, is not appropriate, and will make the inheritance link longer.

  3. The modification has little impact. No matter which class is modified or which class is added, the first solution will require less change to the system.

It should also be noted that the two classifications use aggregation, which makes it easy for abstract classes to associate multiple implementation classes.

2. Application scenarios

The bridge pattern should be considered when we find that we need to classify implementation objects from multiple perspectives, and that inheritance alone will result in a large number of classes that do not satisfy the open-closed principle.

In my previous job, user access was supported by SMS, Email, AppPush, and in-site messaging, but these methods were not systematic and scattered in each code. Later, I wanted to do user journey, and I wanted to systematize these touch methods, but I didn’t do it for various reasons. While we’re at it, write a simple version of the access system.

3. Code implementation

The business scenario of this contact system is as follows: the emergency situation of contact has been defined, the data sources of contact need to be different, and the data (copywriting, recipient, etc.) can be configured according to the emergency situation of contact when operation is used. It can be seen that one category is contact mode and the other is contact emergency.

package main import "fmt" /** * @Description: */ type MessageSend interface {send(MSG string)} /** * @description: */ type SMS struct {} func (s *SMS) send(MSG string) {FMT.Println(" SMS sends a message: "+ MSG)} /** * @description: */ type Email struct {} func (e *Email) send(MSG string) {FMT.Println(" Email ") " + msg) } /** * @Description: Struct {} func (a *AppPush) send(MSG string) {FMT.Println(" AppPush sends a message: " + msg) } /** * @Description: */ struct {} func (l *Letter) send(MSG string) {FMT.Println(" " + msg) } /** * @Description: MessageSends */ struct {messageSends []MessageSend} /** * @description: Contact method, * @receiver * @param MSG */ func (t *Touch) do(MSG string) {for _, s := range t.messageSends { s.send(msg) } } /** * @Description: */ type TouchUrgent struct {base Touch} /** * @description: Emergency message, first get various information from db, Then notify the user * @receiver * @param MSG */ func (t *TouchUrgent) do(MSG string) {FMT.Println("touch urgent ") t.bese.do (MSG)} /** * @description: */ type TouchNormal struct {base Touch} /** * @description: A normal message, which starts by getting various information from a file, * @receiver * @param MSG */ func (t *TouchNormal) do(MSG string) {fmt.println ("touch normal ") Do (MSG)} func main() {// Contact method SMS := &SMS{} appPush := & appPush {} letter := & letter {} email := & Email {} / / choose the way to contact of FMT. Depending on the type of touch of Println (" -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- touch urgent ") touchUrgent: = touchUrgent {base: Touch{ messageSends: []MessageSend{sms, appPush, letter, email}, }, } touchUrgent. Do (" urgent case "), FMT. Println (" -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- touch normal ") touchNormal: = touchNormal {/ / base: Touch{messageSends: []MessageSend{SMS, appPush, email},},} touchNormal.do(" Normal ")}Copy the code

Output:

➜ myproject go run main.go

——————-touch urgent

Touch Urgent Obtains recipient information from db

The SMS message is as follows: Urgent situation

The message sent by appPush is as follows: Urgent Situation

The message content sent by the station is: Urgent situation

The email message is as follows: Urgent Situation

——————-touch normal

Touch Normal retrieves information such as recipients from files

The message content sent by SMS is normal

The message content sent by appPush is normal

The content of messages sent by intra-station letters is normal

The email message content is normal

There are many ways to realize real requirements. One way is to set the type according to the degree of urgency, select the specified type during operation and use, configure copywriting and recipient information, and specify the access mode for the degree of urgency, so that the opening and closing will be better. The other can not set the type, which Touch mode is also selected by the operation itself, if you can ensure that all operations are consistent, Touch class only needs one, do not need to inherit.

conclusion

Bridge mode conforms to open – closed principle, Richter’s substitution principle and dependency reversal principle. To use the bridge pattern, it is important to see if there are multiple categories in the scenario and if there is some correlation between the categories. If so, it is recommended to use the bridge pattern so that the different categories can vary independently without affecting each other.

The last

If you like my article, you can follow my public account (Programmer Malatang)

My personal blog is shidawuhen.github. IO /

Review of previous articles:

recruitment

  1. Bytes to beat | push big 24:00

  2. Bytes to beat | headlines today guangzhou server push r&d engineers

  3. Bytes to beat | trill electricity now hiring front-end development project in Shanghai

  4. Bytes to beat | trill electricity senior server-side development engineer – trading in Shanghai

  5. Bytes to beat | trill electric ShangWuHan server-side development engineer (senior)

  6. Bytes to beat | fly book big customer push product manager

  7. Bytes to beat | trill electricity service side technical posts vacant

  8. Bytedance recruitment special

Design patterns

  1. Go Design Pattern (11)- Proxy pattern

  2. Go Design Mode (10)- Prototype mode

  3. Go Design Mode (9)- Builder mode

  4. Go Design Pattern (8)- Abstract Factory

  5. Go Design Mode (7)- Factory Mode

  6. Go Design Pattern (6)- Singleton pattern

  7. Go Design Pattern (5)- Class diagram symbolic representation

  8. Go Design Pattern (4)- Code writing optimization

  9. Go Design Pattern (4)- Code writing

  10. Go Design Patterns (3)- Design principles

  11. Go Design Pattern (2)- Object-oriented analysis and design

  12. Go Design Pattern (1)- Syntax

language

  1. Understand pprof

  2. Go tool generate

  3. Go singleton implementation scheme

  4. Implementation principle of Go channel

  5. Implementation principle of Go timer

  6. Beego framework use

  7. Golang source BUG tracking

  8. Gin framework concise version

  9. Gin source code analysis

architecture

  1. Payment access general issues

  2. Current limiting 2

  3. Seconds kill system

  4. Distributed systems and consistency protocols

  5. Service framework and registry for microservices

  6. Discussion on Micro-service

  7. Current limiting implementation 1

  8. CDN request process details

  9. Common Cache tips

  10. How to effectively connect with third-party payment

  11. Algorithm is summarized

storage

  1. MySQL development specification

  2. Redis implements distributed locking

  3. The implementation principle of atomicity, consistency and persistence of transactions

  4. InnoDB locks and transactions

network

  1. HTTP2.0 basics tutorial

  2. HTTPS Configuration Combat

  3. HTTPS Connection Process

  4. TCP Performance Optimization

tool

  1. GoLand Practical skills

  2. Automatically generate go struct from mysql table

  3. Markdown editor recommends – Typora

Reading notes

  1. Selected by MAO

  2. The principle of

  3. History As A Mirror

  4. Agile revolution

  5. How to exercise your memory

  6. Simple Logic – After reading

  7. Hot Wind – After reading

  8. Analects of Confucius – After reading

  9. Sun Tzu’s Art of War – Reflections from reading

thinking

  1. Struggle to mobilize all forces for victory

  2. Anti-liberalism

  3. practical

  4. The standard by which you judge yourself

  5. Service team holiday shift plan

  6. Project process management

  7. Some thoughts on project management

  8. Some thoughts on product manager

  9. Thinking about programmer career development

  10. Thinking about code review