Adoption of design patterns in ANDROID-Structural Patterns

Adoption of design patterns in ANDROID-Structural Patterns
The adapter mode, appearance mode, decoration mode, and proxy mode in the zookeeper structural mode belong to the packaging mode. They all wrap other classes or objects, but their intentions are different.

By packaging other classes or objects, the adapter mode converts its interfaces to the desired interfaces for interface adaptation.

The appearance mode provides a high-level interface for a group of encapsulated classes or objects. The intent is to simplify the interface and make the system easier to use.

The purpose of the decoration mode is to add additional functions or responsibilities to the interface without changing the packaging object.

The intent of the proxy mode is to control access to the wrapped object by encapsulating the wrapped object.

The adapter mode and appearance mode vary with the interfaces provided by the customer and the interfaces of the packaging class, that is, these two modes change the access interfaces of the packaging class for the customer. The decoration mode and proxy mode do not change the interfaces of the packaged class externally. The interfaces provided to the customer are the same as those of the packaging class.

1 adapter Mode

There are two types of adapter modes: Class adapter mode and Object Adapter mode. One is the inheritance mode and the other is the object combination mode. The related UML class diagram is as follows:

The adapter mode is widely used in Android systems. Because ANDROID uses the JAVA language and JAVA does not support multi-inheritance, the adapter mode used in the system is mainly the second, it is used to convert the interface of the packaging object to the required interface.

The most common classes in Android system that use the adapter mode are those that inherit from BaseAdapter, such as ArrayAdapter and CursorAdapter, which are used to provide adaptation between the underlying data and the AdapterView, converts the interface for reading the underlying data to the interface required by the view. The class diagram is as follows:

The Client inherited from AdapterView obtains the data required by the view through the Adapter (Target) interface function. For example, the Adapter interface function getItem (int position) obtains the position data item from the underlying dataset, the getCount () function obtains the number of data items in the dataset.

The specific category of the Adapter adapts to different underlying data type reading interfaces. For example, the CursorAdapter class reads data from the underlying database through the Cursor object, and the ArrayAdapter is used to read data from arrays of any types, historyAdapter is used to read data from a vector of HistoryEntry type.

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

2. Appearance Mode

The class diagram of the appearance mode is as follows:

There are many appearance modes used in the Android system. It can be said that each system service provides a management portal class for the customer to access the system service, which is used to facilitate access to the corresponding system service, for example, the window manager corresponding to the window management service, the InputManager corresponding to the management service, and the ActivityManager corresponding to the activity management service.

In addition, ContentResolver, Log, Context, and ServiceManager can also be seen as portal mode adoption.

ContentResolver is used to provide the public interface for the application to access the data mode. Log provides the public interface for the application to use the log output system, and Context provides the interface for the application to access the entire system. ServiceManager provides an entry to access other system services.

3. the class diagram of the decoration mode is as follows:

There are also many examples of using the decoration mode in the Android system. For example, the ContextThemeWrapper class and its derived classes Activity and Service. The UML class diagram is as follows:

ContextWrapper is the packaging of the ContextImpl class. Both the Service class and the Activity class are the derived classes of ContextWrapper. The Service class is directly derived from ContextWrapper, and the Activity is indirectly derived from ContextWrapper subclass contexttheme, the Service and Activity classes add and implement their own lifecycle callback interfaces (hooks) based on the ContextWrapper and ContextThemeWrapper interfaces ), the Activity class also provides functions related to window and view display. The function of ContextThemeWrappe is to add Theme support based on ContextWrapper and perform special processing on the LAYOUT_INFLATER_SERVICE service when the getSystemService interface returns a service management object, returns the cloned object of a LayoutInflater object in the original form mode.

4. Proxy Mode

The proxy mode class diagram is as follows:

The proxy mode is also widely used in Android systems. Each System Service and Local Service correspond to a remote proxy class to implement 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 management service class diagram is as follows:

WindowManagerGlobal is a Proxy object IWindowManager. Stub. Proxy that inherits from the IWindowManager interface to access the system service WindowManagerService.

5. Bridging Mode

The intention of the bridge mode is to separate the abstract part from its implementation part so that they can all change independently. The abstraction and implementation here refer to functional abstraction (or interface) and functional implementation rather than class abstraction and implementation. Any two independently evolved classes with implementation relationships can form a bridge mode. The bridge mode is mainly used in graphics and window systems that need to span multiple platforms. For example, almost all books that introduce the bridge mode are implemented by window and window functions with different features. Different views (or images) and views (or images) as an example of using the bridge mode. The following is the structure of the bridge-mode class diagram:

Similarly, in the ANDROID system, the bridge mode can be used between the view tree composed of different views and the class that completes the view painting function, and between the window class and the window function implementation class. The related class diagram is as follows:

Different views in the figure, such as Button, ImageView, and TextView, constitute an abstract derived hierarchical View tree. In the View tree, View is the root View of all views, view rendering is implemented through three different classes that can be independently evolved: Canvas (providing the drawing surface), HardwareLayer (providing the output display layer), and DisplayList (representing a painting operation ).

The following is a class diagram between windows and window implementation classes in the ANDROID system. Window and PhoneWindow constitute the abstract part of the Window. Window is the abstract interface of the abstract Part. Currently, Window only provides a specific class PhoneWindow. The classes related to the implementation of Window also constitute a derived class diagram, windowManager is the basic class of window implementation, WindowManagerImpl is the specific class of WindowManager, WindowManagerImpl interacts with WindowManagerService through WindowManagerGlobal and the IWindowManager interface, the window management service completes the actual window management function.

The bridging mode is very similar to the adapter mode, except that the scenario and viewing angle are different.

The difference between the bridge mode and the adapter mode in the classical book of GOF is described as follows: the structure of the B r I d g e mode is similar to that of the Object Adapter, the differences between the two modes mainly lie in their respective purposes and starting points: the purpose of B r I d g e is to separate the Interface part and implementation part and bridge them, thus, they can be easily changed and evolved relatively independently. The B r I d g e mode can provide users with a stable abstraction and Its Implementation interface. In the d a p t e r mode, the interface of an existing object is changed to solve the non-matching between two existing interfaces, which helps to implement coordination between incompatible classes, the A d a p t e r mode does not consider how these interfaces are implemented, nor how they may evolve. Therefore, A d a p t e r is usually used after the system design is complete, while the B r I d g e mode must know in advance that an abstract will have multiple implementations, therefore, it is used at the beginning of the system.

Therefore, from the above description, we can see that a completed code that adopts the bridge or adapter mode can be viewed as the bridge mode or the adapter mode from different points of view.

6. Combination Mode

The intention of the combination mode is to combine objects into a tree structure to represent a "part-whole" hierarchy. C o m p o s I t e makes the use of a single object and a composite object consistent. The following is the class graph structure:

The standard examples using the combination mode are graphics, views, menus, and Windows. Collection classes (such as arrays) and file directories can also be seen as using the combination mode. The following is a composite view class chart in the ANDROID system using the composite mode:

7-element mode

The intention of the meta-mode is to use the sharing technology to effectively support a large number of fine-grained objects. The class graph structure is as follows:

The metadata sharing mode is also widely used.

In the ANDROID system, each application component can use a variety of service management objects provided by the system, such as WallpaperManager, AccessibilityManager, CaptioningManager, and AccountManager. Therefore, to share these objects within a component, In the ContextImpl Implementation of the Context of the application component, when the ContextImpl class loads the reference for the first time, a ServiceFetcher object (using a static code block) is created for each management object, and the newly created ServiceFetcher object is placed in the MAP set according to the service name, each ServiceFetcher object is assigned an index when it is registered to the MAP set.

The application component calls the Context. when getSystemService obtains the system service management object, it first obtains the corresponding ServiceFetcher object from the MAP set according to the service name, and then calls the getService function of the ServiceFetcher object to obtain the service management object created by the ServiceFetcher object.

In the getService function of the ServiceFetcher object, first find whether the service management object created by the ServiceFetcher object contains the ServiceFetcher object in the Cache array list maintained by Context based on the index of the ServiceFetcher object, if a service management object exists in the Cache, the service management object saved in the Cache is directly returned. Otherwise, the createService function of ServiceFetcher is called to create a service management object, and place it into the Cache based on its index for future use.

All rights reserved. Please clearly indicate the source and link when reprinting. Thank you!

Zookeeper