The adoption of design patterns in ANDROID--structural patterns

structureMode, the adapter mode, the appearance mode, the adornment mode, the proxy mode all belong to the packing mode, is the wrapper to the other class or the object, but the respective intention is different.

Adapter mode through the packaging of other classes or objects, the interface is converted to the user's desired interface, to achieve the purpose of interface adaptation.

The appearance mode provides a high-level interface to a packaged set of classes or objects, with the intention of simplifying the interface and making the system easier to use.

The intent of the decorating mode is to add additional functions or responsibilities to the wrapper object without changing its interface.

The intent of the proxy mode is to control the access to the wrapper object by wrapping the wrapper object.

Adapter mode, appearance mode the interface between the client and its wrapper class is different, that is, these two modes for the customer to change the wrapper class access interface. While the decorative mode, proxy mode does not change the interface of the wrapper class, the interface provided to the customer is the same as the interface of the wrapper class.

1 Adapter mode

There are two types of adapter modes: Class Adapter Mode and the object adapter pattern, one uses the inheritance method, one uses the object composition method, the related UML class diagram is as follows:

Android The adapter mode in the system is heavily adopted, because ANDROID uses the Java language, and the Java language does not support multiple inheritance, so the adapter pattern used in the system is mainly the second type, Used to convert the interface of the wrapper object to the desired interface.

The most commonly used adapter-mode classes in Android are classes that inherit from Baseadapter , such as Arrayadapter,cursoradapter , and so on. Used to provide an adaptation between the underlying data and the Adapterview view to transform the read interface of the underlying data into the interface required by the view. The class diagram is as follows:

      " inherits the view of adapterview by adapter Span style= "font-size:14px" > (Target) interface function to obtain the data required by the view, such as adapter interface functions getitem (int position position Data item, getcount () function to get the number of data items in the data set.

The specific class of Adapter completes the adaptation of the read interface to different underlying data types, such as the CursorAdapter class reading data from the underlying database through a Cursor objectarrayadapter used to read data from any type of list array,Historyadapter is used to read data from a vector of type historyentry .

Other uses of the adapter mode are the display of the DisplayAdapter class in the service and the Printdocumentadapter class in the print service. DisplayAdapter is used to adapt different types of display devices to detect and discover different types of devices connected to the system. The printdocumentadapter is used to adapt different print output target devices, such as printers or files, to output printed content on these devices.

2. appearance mode

the class diagram for the appearance pattern is as follows:

There are many places to use the appearance mode in Android , it can be said that each system service provides a management portal class to the customer to access the system services, for easy access to the corresponding system services, such as the Window Management service corresponding to the WindowManager, enter the corresponding InputManagerfor the Management Service, Activitymanager for the Activity Management Service, and so on.

another contentresolver ,Log,Context,ServiceManager can also be seen as the adoption of portal mode.

The contentresolver is used to provide a common interface for applications to access data patterns, andlog provides a common interface for applications that use the log output system,Context Provides an interface for applications to access the entire system. ServiceManager provides access to other system services.

3 Decoration Modethe class diagram for the decorating mode is as follows:

There are also many examples of using decorative patterns in Android systems. such as the Contextthemewrapper class and its derived classes Activity and Service. The UML class diagram is as follows:

Contextwrapperis toContextimplPackaging of Classes, ServiceClasses andActivityClasses areContextwrapperthe derived class,Service class derives directly fromContextwrapper,Activityindirectly derived fromContextwrappersub-classContextthemewrapper,ServiceClasses andActivityclass, respectively, inContextwrapperand theContextthemewrapperand implements the respective lifecycle callback interface (hooks) based on the interface of the class,Activity The class also provides functionality related to the window and view display associated with it. The function of Contextthemewrappe is to add a contextwrapper based on the theme ( Theme) is supported and is returned to the service management object through the getsystemservice interface for Layout_inflater_service The service has been specially processed to return a cloned object of a Layoutinflater object using prototype mode .

4. Proxy Mode

The class diagram for the proxy mode is as follows:

proxy mode is also common in Android , with each system service and local service corresponding to a remote proxy class for cross-process access to system services or local services. Each system service is a stub object, and the client accesses the corresponding stub object through a Proxy object. For example, the class diagram for Management Management Services is as follows:

Windowmanagerglobal as a client through a proxy object inherited from the interface iwindowmanager IWindowManager.Stub.Proxy Cross-process access to system service Windowmanagerservice.

5, bridge - mode

The intent of the bridging mode is to separate the abstract part from its implementation, so that they can vary independently. The abstraction and implementation here refer not to the abstraction and implementation of the class, but to the function abstraction (or interface) and the function implementation. Any of the two independent evolutionary derived classes that have an implementation relationship can form a bridging pattern that is primarily used on graphics and windowing systems that need to span multiple platforms. As with all of the books that introduce bridging patterns, almost all are implemented with different features of Windows and Windows, and different views (or graphs) and views (or graphics) are drawn as examples of bridging patterns. The following is the class diagram structure of the bridging mode:

Bridging mode can also be considered between the view tree of different views in the ANDROID system and the class that completes the drawing function of the view, and between the window class and the function implementation class of the window. The related class diagram is as follows:

  

          button , imageview , Span lang= "en-us" >textview constitutes an abstract derived hierarchical view tree, view view is implemented by three different classes that can evolve independently: canvas (provides drawing surfaces), (provides output display layer), displaylist (represents a drawing operation).

The following is a class diagram between Windows and Windows implementation classes in ANDROID systems. window, which is the abstract part of the phonewindow , Windows is the abstract interface of the abstract part, window currently only provides a specific class Phonewindow, The implemented partial class of window also forms a derived class diagram,windowmanager the base class for the Window implementation section,Windowmanagerimpl for the specific class of WindowManager ,windowmanagerimpl through windowmanagerglobal and through The Iwindowmanager interface interacts with the window Management Service Windowmanagerservice , which completes the actual window management function by the window Management Service.

         bridging is very similar to adapter two modes, Just use the occasion and the angle of observation is different.

       in gof the design pattern of the classical Classic in the bridge mode and adapter mode is described as: b R i d g e-mode structure similar to the object adapter, Two modes differ mainly in their respective uses and the starting point: b R i d g e is designed to separate and bridge the interface and implementation parts, Thus they can be more easily and relatively independent of the change and evolution, b R i d g E The mode provides the user with a stable abstraction and its implementation interface . and a D A p T e r mode by changing an existing object interface to , To help implement incompatible classes that work together, a D A p T e r mode a D A p T e r is usually used after the system design is complete, and b R i d g e mode You must know beforehand that an abstraction will have more than one implementation part, so is used

Therefore, it can be seen from the above description that the use of a bridge or The completed code for the adapter pattern can be viewed as a bridging mode from different viewing angles, or as an adapter mode.

6. Combination Mode

the intent of the composition pattern is to combine objects into a tree structure to represent a "partial - whole" hierarchy. C o m P o s i t e makes the user consistent with the use of a single object and a composite object. The following is the class diagram structure:

the standard examples of combining patterns are graphs, views, menus, and windows, and collection classes (such as arrays) and file directories can also be used as combination patterns. The following is a combined view class diagram in the ANDROID system using the combined mode:

7 enjoy meta mode

Enjoy meta-mode intended to effectively support a large number of fine-grained objects using shared technology, the class diagram structure is as follows:

              

        in android system, each application component can use many of the system-provided service management objects, such as wallpapermanager , accessibilitymanager , captioningmanager , Accountmanager and so on. Therefore, in order to share these objects within a component, the implementation of the context in the application component contextimpl , contextimpl class The first time a reference is loaded, a servicefetcher object (with static code blocks) is created for each management object And puts the newly created servicefetcher object into the map collection according to the service name, each servicefetcher object is assigned an index when it is enlisted into the map collection.

         When the application component calls context.getsystemservice to obtain a system service management object, it begins with the service name map collection to obtain the corresponding servicefetcher object, and then call Servicefetcher object getservice function obtains servicefetcher The service management object that the object creates.

In the getService function of the servicefetcher object, first from the list of Cache arrays maintained by the Context , according to Servicefetcher whether an index lookup for an object already contains a service management object created by the Servicefetcher object, and if a service management object exists in the cache , the service management object that is saved in the cache is returned directly , otherwise call Servicefetcher 's createservice function to create a service management object and place it in the Cache based on its index for the next use.

All rights reserved, please clearly indicate the source and link when reproduced, thank you!