"Android source design mode analysis and actual combat" reading notes (24)

24th Chapter, Bridging mode

Bridge mode, also known as bridge mode, is one of the structural design patterns. The bridge mode embodies the principle of single duty, the principle of opening and closing, the principle of replacing the Richter scale, and the principle of dependency inversion. At the same time it is also a very practical mode.

1. Definition

Separate the abstract parts from the real ones so that they can all be changed independently.

2. Usage Scenarios

(1) If a system needs to add more flexibility between the abstract and specific roles being built, avoid establishing static inheritance links between the two levels.

(2) You can also consider bridging mode for systems that do not want to use inheritance or because the number of system classes is dramatically increased due to multi-level inheritance.

(3) A class has two independently changing dimensions, and these two dimensions need to be expanded.

3.UML class Diagram

(1) Abstraction : Abstract part, the class maintains a reference to the implementation of partial objects, the method in the abstract part needs to call the implementation of the object to implement, the class is generally abstract class.

(2) RefinedAbstraction : The optimization of the abstract part, the specific implementation of the abstract part, the class is generally the abstract part of the method to improve and expand.

(3) Implementor : implementation section. It can be an interface or an abstract class whose methods are not necessarily consistent with the abstract part, generally by providing basic operations by the real part, while the abstract part defines the business method based on the implementation of these basic operations.

(4) ConcreteImplementorA , ConcreteImplementorB : implementation of the specific implementation of the part. Refine the specific logic of the method definition in the implementation section.

4. Simple implementation

Take coffee in the coffee shop for example, we assume that coffee has a large cup of sugar, a large cup without sugar, a small cup of sugar and a small cup without sugar four.

Abstract class for adding something to coffee: (implementor)

publicabstractclass CoffeeAdditives {    /**     * 具体要往咖啡里添加什么东西      *      * @param 具体添加的东西     */    publicabstractaddSomething();}

Add sugar to achieve: (Concreteimplementora)

publicclass Sugar extends CoffeeAdditives{    @Override    publicaddSomething() {        return"加糖";    }}

Plain class implementation: (Concreteimplementorb)

publicclass Ordinary extends CoffeeAdditives{    @Override    publicaddSomething() {        return"原味";    }}

Coffee type: (abstraction)

publicabstractclass Coffee{    protected CoffeeAdditives impl;    publicCoffee(CoffeeAdditives impl) {        this.impl = impl;    }    /**     * 咖啡具体什么样由子类决定      */    publicabstractvoidmakeCoffee();}

Large cup OF coffee: (refinedabstraction)

publicclass LargeCoffee extends Coffee{    publicLargeCoffee(CoffeeAdditives impl) {        super(impl);    }    @Override    publicvoidmakeCoffee() {        System.out.println("大杯的""咖啡");    }}

Small cup OF coffee:

publicclass SmallCoffee extends Coffee{    publicSmallCoffee(CoffeeAdditives impl) {        super(impl);    }    @Override    publicvoidmakeCoffee() {        System.out.println("小杯的""咖啡");    }}

Call:

 Public classClient { Public Static void Main(string[] args) {//OriginalOrdinary implordinary =NewOrdinary ();//Add sugarSugar Implsugar =NewSugar ();//Large cup OF coffee flavorLargecoffee largecoffeeordinary =NewLargecoffee (implordinary); Largecoffeeordinary.makecoffee ();//small cup OF coffee flavorSmallcoffee smallcoffeeordinary =NewSmallcoffee (implordinary); Smallcoffeeordinary.makecoffee ();//Large cup of coffee and sugarLargecoffee Largecoffeesugar =NewLargecoffee (Implsugar); Largecoffeesugar.makecoffee ();//small cup of coffee and sugarSmallcoffee Smallcoffeesugar =NewSmallcoffee (Implsugar);    Smallcoffeesugar.makecoffee (); }}

Results:

大杯的原味咖啡小杯的原味咖啡大杯的加糖咖啡小杯的加糖咖啡

Bridge mode 1.Window and WindowManager in 5.Android source code

The main code is as follows:

 Public Abstract  class Window {   //Part omitted   /** * Set The window manager for use by this window to, for example, * display panels.     This was <em>not</em> used for displaying the * Window itself – that must was done by the client.     * * @param wm the window manager for adding new windows. */     Public void Setwindowmanager(WindowManager wm, IBinder Apptoken, String appName) {Setwindowmanager (WM, Apptoken, AppName,false); }/** * Set The window manager for use by this window to, for example, * display panels.     This was <em>not</em> used for displaying the * Window itself – that must was done by the client.     * * @param wm the window manager for adding new windows. */     Public void Setwindowmanager(WindowManager wm, IBinder Apptoken, String appName,Booleanhardwareaccelerated) {mapptoken = Apptoken;        Mappname = AppName; mhardwareaccelerated = hardwareaccelerated | | Systemproperties.getboolean (PROPERTY_HARDWARE_UI,false);if(WM = =NULL) {wm = (WindowManager) mcontext.getsystemservice (Context.window_service); }//* bind window to WindowManagerMwindowmanager = ((Windowmanagerimpl) WM). Createlocalwindowmanager ( This); }//Part omitted}

6. Summary 1. Advantages

(1) Separation of abstraction and reality, flexible expansion, and transparent implementation to the customer.

(2) Bridging mode can replace multi-layer inheritance, greatly reducing the number of sub-classes.

2. Disadvantages

Not easy to design, for developers to have a certain degree of experience required. Understanding is easy, but design is not easy.

"Android source design mode analysis and actual combat" reading notes (24)