Analysis of Android source code design patterns and practices (23rd)

Analysis of Android source code design patterns and practices (23rd)
Chapter 2 appearance Mode

The appearance mode is one of the structural design modes. It is frequently used in development and is a common method for encapsulating APIs. Third-party sdks we often use are basically used in the appearance mode, which can shield users from many implementation details and reduce user costs.

1. Definition

It is required that the external communication of a sub-system and its internal communication must be performed through a unified object. The appearance mode provides a high-level interface to make the subsystem easier to use.

2. Use Cases

(1) provides a simple interface for complex subsystems to hide the specific implementation and isolation changes of subsystems.

(2) When you need to build a layered sub-system, use the appearance mode to define the entry points for each layer of the sub-system. If subsystems are mutually dependent, you can allow them to communicate only through the appearance interface, thus simplifying the dependency between them.

3. UML class diagram

(1)Facade: A unified interface for the system to work in the system.

(2)Other branches: Subsystem interface.

It can be seen that the appearance mode structure is very simple, but if there is no encapsulation, the user needs to operate the interaction logic of several subsystems, which is prone to errors.

4. simple instance

The mobile phone integrates functions such as phone, SMS, camera, and GPS. Take the mobile phone as an example to simply implement it in the appearance mode.

Phone interface and PhoneImpl:

Public interface Phone {// call public void dail (); // call public void hangup ();}

Public class PhoneImpl implements Phone {@ Override public void dail () {System. out. println ("call") ;}@ Override public void hangup () {System. out. println ("hanging up ");}}

The Camera interface and the implementation class of Camera:

Public interface Camera {// open the Camera public void open (); // take a photo public void takePicture (); // close the Camera public void close ();}

Public class SamsungCamera implements Camera {@ Override public void open () {System. out. println ("turn on the camera") ;}@ Override public void takePicture () {System. out. println ("photo") ;}@ Override public void close () {System. out. println ("turn off the camera ");}}

Appearance class MobilePhone:

Public class MobilePhone {private Phone mPhone = new PhoneImpl (); private Camera mCamera = new SamsungCamera (); public void dail () {mPhone. dail ();} public void hangup () {mPhone. hangup ();} public void takePicture () {mCamera. open (); mCamera. takePicture ();} public void closeCamera () {mCamera. close ();} public void videoChat () {System. out. println ("--> video chat connection"); mCamera. open (); mPhone. dail ();}}

Call:

Public class Client {public static void main (String [] args) {MobilePhone mobilePhone = new MobilePhone (); // photograph mobilePhone. takePicture (); // video chat mobilePhone. videoChat ();}}

Result:

Enable the camera to take a photo --> enable the camera to make a phone call in the video chat connection.

5. Appearance mode in Android Source Code 1. Context

ContextIs an abstract class, and its true implementation isContextImplClass, ViewContextImplWe can see the source codeContextImplOperations on different subsystems are encapsulated internally. For example, activities jump, send broadcasts, start services, and set wallpapers.ContextImplBut to a specific sub-system for processing. PassContextThis abstract class defines a set of interfaces,ContextImpl. In this way, users usually do not need to understand each subsystem. In this way, the specific implementation details are shielded and the cost is reduced.

6. Summary 1. Advantages

(1) hiding sub-system details in customer programs reduces the coupling between sub-systems and embraces changes.

(2) The appearance class encapsulates subsystem interfaces, making the system easier to use.

2. Disadvantages

(1) The appearance interface expands. Because all the sub-system interfaces are externally exposed, there are many APIs for the appearance class, which increases the user cost to a certain extent.

(2) The appearance class does not follow the principle of opening/closing. When the business changes, you may need to directly modify the appearance class.