The bridge model

The official definition of

Separate the abstraction from its implementation so that both can change independently.

Characteristics and personal understanding

1. Decouple abstract and real business operations

Some common operations are abstracted out as a utility function, and different functions are performed by passing parameters, such as encapsulating axiOS request methods

// tool.js
export let sendRequest {
    get(url,params) {
        // Handle the parameters of the GET request
        return promise = axios({
            method: 'get',
            url,
            params:params
         }).then(() = > {
            // Handle the return of the GET request})},post(url,params) {
        // Handle the parameters of the POST request
        return promise = axios({
            method: 'post',
            url,
            data:params
         }).then(() = > {
            // Handle the return of the POST request})},put() {},
    delete() {},
    option() {},   // This can be extended later according to different request methods
}


//api.js
export let api = {
    api1: '/test/api1'.api2: '/test/api2'.// This can be extended later depending on the API
}


// The specific business page
this.sendRequest.get(api1,{a:1}).then(() = > { // Specific business})
this.sendRequest.post(api2,{b:2}).then(() = > { // Specific business})
Copy the code

The best part of the above example is that the method of the request is abstracted and encapsulated, and the method and path of the request are separated as parameters to facilitate future expansion. However, this example is not enough because the comparison between the two dimensions of the request method and request path is often unique, that is, it is usually GET for API1 and POST for API2. (API1-POST, API2-GET is not required) it does not reflect the second characteristic of the bridge pattern.

2. Two different dimensions of development

Suppose there is a coordinate axis. The horizontal axis is the payment channel (wechat, Alipay, JD, Meituan, Flash Payment and other payment platforms), and the vertical axis is the payment method (face brush, password, fingerprint, etc.). Any point on the horizontal axis can correspond to each point on the vertical axis and perform different functions

if(pay ="WeChat") {if (payType = "Brush face") {} else (payType = "Password") {}}else { pay = "Alipay") { 
    if (payType = "Pay with your face") {} else (payType = "Pay by Password") {}}Copy the code

To put one or two together is to put two dimensions that interweave with each other and produce a variety of variations (i.e., X1-y1,x1-y2; X2-y1, X2-y2) becomes a utility function in an abstract way, easy to use in different scenarios, and easy to grow and maintain these two dimensions

Application of bridge mode in front end

Here’s a simple example: abstract a method to add operations to a DOM node. X axis is the different DOM node (dom1,dom2,dom3),y axis is the common node event (change style, clear float, stopPropagation, preventDefault)


// Abstract methods
function addEvent(ele, fn) {
    document.querySelector(ele).addEventListener('click', fn, false); 
}

// Common basic operations
function changeStyle(dom) { 
    dom.style.color = 'red';
};
function preventDefault(dom) { 
    dom.preventDefault();
};

// Make different combinations according to the business
addEvent('.dom1',changeStyle())
addEvent('#dom2',preventDefault())


Copy the code

conclusion

  1. The bridge pattern is appropriate when there are two dimensions and there are multiple mappings or when the dimensions grow over time
  2. A function needs to be abstracted, which may be difficult when the business is more complex and the business scenario is very special.
  3. Very good for future extensibility and maintainability of the code