I. Six principles of design mode

Before going into architectural design, let’s talk about the six principles of design patterns. Although these are the six principles of design patterns, we should try to follow these principles when designing architecture.

The six principles are abstract and not easy to understand if viewed only in concept. Here’s an example from life: cars are the base class; A car is a subclass of automobile; Cars are all on the road, so we abstract the road as an interface, let the car implement this interface; Cars can be used to carry people, so we abstract people into an interface, let the car to achieve this interface; Cars can also carry chicken, duck and fish, but need to carry up through people, so put chicken, duck and fish into the interface of people;

The following is an official explanation of each of these principles, followed by the example of cars.

1. Principle of single responsibility

There should be only one reason for a class to change;

Here we design the car class to meet the single duty, its single duty is to run on the road;

2. Principle of openness and closure

Classes, modules, and functions should be extensible, but not modifiable;

Here, we adopt the open and closed principle for cars. Cars extend functions by inheriting cars without modifying the base class of cars.

3, reliance inversion principle

High-level modules should not depend on low-level modules, both should depend on abstraction, abstraction should not depend on details, details should depend on abstraction;

In this case, our car class implements the road interface, which relies on abstraction; The highway interface is an abstraction;

4. Interface isolation principle

The dependency of one class on another should be based on the smallest interface;

Here, the car implements two interfaces, road and human. Each interface is responsible for its own aspect, namely interface isolation.

5. Richter’s substitution principle

All references to a base class must transparently use objects of its subclasses;

Wherever a car is needed in this example, there is no problem with a car; But where cars are needed, they cannot be introduced;

6. Demeter principle

A software entity should interact with as few other entities as possible;

In this example, our car can carry chicken, duck and fish, but they need to be carried by people. Therefore, we do not abstract the interface for chicken, duck and fish separately, but put them into the interface of people, so that the car can interact with other entities as little as possible.

Ii. Architecture introduction

If we do not use architectural thinking in development, then all the code will be in an activity or fragment, and the business needs are complex and changeable, and need to be changed frequently. Data, views, and logic all put together can appear chaotic, extremely difficult to maintain, and difficult to troubleshoot errors; Before introducing the three architectures, let me introduce a few concepts;

Data model: Data includes the data itself and the logic for data manipulation. Data has its own operation logic, which does not involve views.

View view: Different architectural modes of view represent different parts, which are described separately below;

Control logic: Different architectural patterns have different control parts;

1, the MVC

View in MVC mode refers to the XML file and the part of the activity associated with the view, such as findViewById and other operations. In MVC mode, C refers to controller, which is actually an activity or fragment. Logical control is carried out in the activity to make data and view interact.

The MVC pattern takes a little bit of the burden off the Activity by removing the Model layer, but it’s still complicated because the logic needs to be controlled in the activity, and the interaction between data and view needs to be in the activity.

2, the MVP

In MVP mode, V represents the view layer, which mainly includes XML files and activities. View-related operations are carried out in activities.

In MVP mode, P represents presenter control layer, which mainly carries out logical control and makes the data layer and view layer interact. Presenters can hold data and view objects in a presenter. How are views held? The general way is to define the view IView interface, in the interface to define the method to change the view, so that the activity interface, and then in the activity to implement the method specific logic; In this way, we can hold an interface object in the Presenter and assign a value to the interface object in the constructor. When we instantiate the presenter in the activity, we can pass in the presenter itself, thus implementing the IView interface. In this way, we can manipulate methods in the presenter interface, which enables view and data interaction.

MVP has the advantage of separating the control part into presenter, completely separating data from view. The disadvantage is that more interfaces need to be defined, and methods added or modified in the interface need to go to multiple places to modify;

3, MVVM

I am afraid to understand MVVM in two cases, one is to use dataBinding; One is to not use dataBinding;

Not using dataBinding:

As shown below, the UI control layer can represent activities and fragments. The ViewModel layer can be implemented using the ViewModel in JetPack, which typically defines multiple LiveData to watch. The warehouse layer is used to determine whether to access data from local data sources or network data sources. SP, database and other containers can be used if it is from a local data source. If it is from the network data source, we can use Retrofit, Okhttp and other three-party frameworks to implement;

Graph TD UI control layer --> ViewModel layer --> Warehouse layer --> Warehouse layer --> local data source model --> Persistent file network data source model --> WebService

Use dataBinding:

The case for using dataBinding is to turn the view XML into a view implemented by dataBinding, associate the view with the data, and update it automatically;

In MVVM mode, M still represents the Model data layer. V represents the view layer, which mainly includes XML files and activities. The VM represents the ViewModel layer, and generally defines the observable containers in dabaBinding in the ViewModel, then logically modifies those containers, then introduces the objects of the ViewModel in the XML view, and then observes the observable containers in the ViewModel in the concrete view. So if you make changes to the container in the viewModel, the update will be synchronized in the view;

MVVM implements the separation of data, view, and logic without redundant interfaces. Easy to modify, data and view to observe each other; The downside is that you need to write a little code in the XML file.