iOS development architecture

1. Principles of original structure

The seven principles of software architecture are as follows:

1. Open and close principle
2. Dependency Inversion Principle
3. Single Responsibility Principle
4. Interface Segregation Principle
5. Dimit's law (minimum knowledge principle)
6. Liskov Substitution Principle
7. Synthesis/Aggregation Reuse Principles

1. Open and close principle

Open for extension, closed for modification .

That is to say, when designing a module, the module should be able to be extended without being modified. In other words, it should be possible to
change the behavior of the module without modifying the source code, while maintaining a certain stability of the system On the basis of the system, expand the system.

For example: the upgrade of general software functions needs to comply with the principle of opening and closing, that is, not to modify the original code, but to add new functions.

2. Dependency Inversion Principle

The implementation relies on abstraction as much as possible, not on concrete implementation.
This principle has the following three points:

• 1. High-level modules should not depend on low-level modules, both should depend on abstractions.
• 2. Abstraction should not depend on details, that is, concrete implementation classes.
• 3. Details should depend on abstractions.

The benefits brought by this can reduce the coupling between classes, improve the stability of the system, improve the readability and maintainability of the code, and reduce the risk caused by modifying the program.

This is what we usually call interface-oriented programming .

3. Single Responsibility Principle

For a class, there should be only one reason for the class to change.

This principle literally means: a class, interface, and method have as single a responsibility as possible . In this way, we can decouple well, and later requirement changes and maintenance will not affect each other, which can reduce the complexity of the class and improve readability.

4. Interface Segregation Principle

The client should not rely on interfaces it does not need, and the dependencies between classes should be established on the smallest interface.
This principle guides us to pay attention to the following points when designing interfaces:

• 1. The dependence of a class on another class should be based on the smallest interface.
• 2. Establish a single interface instead of a general interface with many functions.
• 3. Try to refine the interface as much as possible, and the methods in the interface should be as few as possible (not the less the better, it must be moderate).

This principle conforms to the design idea of ​​high cohesion and low coupling , which can make the class have good readability, scalability and maintainability .

5. Demeter's law (minimum knowledge principle)

An object should keep a minimum of knowledge about other objects, minimizing class-to-class coupling.

Because each class minimizes its dependence on other classes, it is easy to make the functional modules of the system independent, and there is no (or very little) dependency relationship between them. Demeter's law does not want to establish a direct connection between classes. If there is a real need to establish a connection, I hope it can be conveyed through his friend class.

The Dimit principle mainly emphasizes only communicating with friends and not talking to strangers. Classes that appear in member variables, method input, and output parameters can be called member friend classes, while classes that appear in method bodies do not belong to friend classes.

6. Liskov Substitution Principle

If a software entity is applicable to a parent class, it must be applicable to its subclass. All references to the parent class must be able to use its subclass objects transparently. Subclass objects can replace parent class objects, while the program logic remains unchanged. .

Let's summarize: subclasses can extend the functions of the parent class, but cannot change the original functions of the parent class.

• 1. The subclass can implement the abstract method of the parent class, but cannot override the non-abstract method of the parent class.
• 2. Subclasses can add their own unique methods.
• 3. When the method of the subclass overrides the method of the parent class, the preconditions of the method (that is, the input/parameters of the method) are looser than the input parameters of the parent method.
• 4. When the method of the subclass implements the method of the parent class (overriding/overloading or implementing an abstract method), the postcondition of the method (that is, the output/return value of the method) is stricter or equal to that of the parent class.

Using the Liskov substitution principle has the following advantages:

• 1. The overflow of constraint inheritance is a manifestation of the principle of opening and closing.
• 2. Strengthen the robustness of the program, and at the same time, it can achieve very good compatibility when changing, and improve the maintainability and scalability of the program. Reduce the risk introduced when requirements change.

7. Synthesis/aggregation reuse principles

Try to use object composition (has-a)/aggregation (contanis-a) instead of inheritance relationship to achieve the purpose of software reuse.

In other words, it is to use some existing objects in a new object to make them part of the new object, and the new object achieves the purpose of reusing existing functions through the delegation of these objects.

This principle can make the system more flexible, reduce the degree of coupling between classes, and the change of one class has relatively little impact on other classes.

Two, MVC architecture

MVC is short for Model-View-Controller . MVC has three main layers:

• Model : data layer, read and write data, save App state.
• View : The page layer, interacting with users, displaying pages to users, and giving feedback on user behavior.
• ViewController : logic layer, update data, or page, handle business logic.

MVC can help you separate data, pages, and logic codes. Make each layer relatively independent. In this way, you can extract some reusable functions and simplify them. However, once the interaction of App becomes complicated, you will find that ViewController will become very bloated. A lot of code is added to the controller , making the controller overburdened.

Here is a special note : If it is just to solve the short board of bloated code in VC, split the logic code in VC according to functional modules using **category**, and only keep the necessary calling interface can effectively reduce VC The problem of bloated code.

3. MVVM architecture

MVVM is the abbreviation of Model-View-ViewModel . It is a new architectural framework developed and evolved from the combination of MVP (Model-View-Presenter) mode and WPF.

The MVVM shelf results are as follows:

• Model : Data layer, read and write data, and save App state.
• View : page layer, providing user input behavior and displaying output status.
• ViewModel logic layer, which converts user input behavior into output state.
• ViewController : Mainly responsible for data binding.

In fact, it is more appropriate to call the MVVM-C architecture here .

ViewModel is the logic layer, while Controller only needs to be responsible for data binding. In this way, the burden on the controller is reduced a lot. And ViewModel is independent from controller and page . Well, you can use it cross-platform. You can also test it easily.

The MVVM mode uses the data binding infrastructure, which is the core of the MVVM design mode. In use, the two-way binding technology is used to make the ViewModel automatically update when the Model changes, and the View also automatically changes when the ViewModel changes. ViewModel contains all UI-specific interfaces and properties, and has a binding property of ViewModel's view. When the bound property changes, View will automatically update the view, so the logic of updating the view can be placed in ViewModel, reducing the Controller code, iOS implements this binding using notifications and KVO .

ViewModel is actually equivalent to a black box, which receives input and produces results through internal business logic processing.

##4. Summary
This article mainly introduces the seven principles of software architecture , the MVC architecture pattern , and the MVVM architecture pattern .

No matter which architectural pattern we choose, we are all moving towards code scalability , maintainability , reusability , and readability . Our ultimate goal is to reduce the coupling of the code and facilitate subsequent modification, expansion and maintenance .

The biggest feature of MVVM mode and MVC mode is not to reduce the bloated code in VC, but the MVMM architecture mode unifies business logic into VM for processing, which is convenient for unit testing and automated testing.

In actual development, we must choose the architecture model according to our actual situation. Don't blindly pursue new ones. The architecture model that suits your current business is the best architecture model.

The above are just personal opinions, if you have different opinions, please feel free to enlighten me.

References

Introduction to MVVM in RxSwift, the Seven Principles of Software Architecture