I. Principles of original architecture
The seven principles of software architecture are as follows:
- The open closed principle
- Dependency inversion principle
- Single responsibility principle
- Interface Isolation Principle
- Demeter’s law (least know principle)
- Richter’s substitution principle
- Synthesis/polymerization reuse principle
1. Open and close principle
Open for extensions, closed for modifications.
A module should be designed so that it can be extended without modification. In other words, it should be possible to change the behavior of the module without modifying the source code, extending the system while maintaining some stability.
For example, the general software function upgrade needs to conform to the open closed principle, that is, do not modify the original code, but to add new functions.
2. Dependency inversion principle
The implementation relies on abstraction rather than concrete implementation. This principle is illustrated by 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, namely concrete implementation classes.
- 3. Details should depend on abstraction.
The benefits are reduced coupling between classes, improved system stability, improved code readability and maintainability, and reduced risk of program modification.
This is what we usually call interface oriented programming.
3. Principle of single responsibility
There should be only one cause for a class to change.
This principle literally means that a class, interface, or method should have as few responsibilities as possible. This allows us to decouple our classes so that later requirements changes and maintenance do not interfere with each other, reducing class complexity and improving readability.
4. Interface isolation principle
A client should not rely on interfaces it does not need, and dependencies between classes should be based on the smallest interface. This principle guides us to consider the following points when designing interfaces:
- 1. The dependency of one class on another class should be based on the smallest interface.
- 2, establish a single interface, do not establish a variety of functions of the general interface.
- 3, try to refine the interface, the interface method as little as possible (not the less the better, must be moderate).
This principle conforms to the design idea of high cohesion and low coupling, which can make the class have good readability, extensibility and maintainability.
5. Demeter’s Law (Least Know Principle)
One object should know as little about other objects as possible, minimizing the coupling between classes.
Because each class minimizes its dependence on the others, it is easy to make the functional modules of the system functionally independent, with no (or few) dependencies on each other. Demeter’s rule does not want direct connections between classes. If there is a real need to establish contact, also hope to communicate through his friends class.
The Demeter principle emphasizes only talking to friends, not strangers. Classes that appear in member variables, input parameters, and output parameters of a method are called member friend classes. Classes that appear inside a method body are not friend classes.
6. Richter’s substitution principle
If a software entity applies to a parent class, it must apply to its subclasses. All references to the parent class must be able to transparently use its subclass objects, which can replace the parent class objects without changing the program logic.
To summarize, a subclass can extend the functionality of its parent class, but cannot change the functionality of its parent class.
- A subclass can implement abstract methods of its parent class, but cannot override non-abstract methods of its parent class.
- 2. Subclasses can add their own special methods.
- 3. When a subclass’s method overrides a parent’s method, its preconditions (i.e. its input/input parameters) are looser than the parent’s input parameters.
- 4. When a subclass’s method implements a parent class’s method (overriding/overloading or implementing an abstract method), the method’s postcondition (that is, the method’s output/return value) is stricter or equal to that of the parent class.
Using the Richter substitution principle has the following advantages:
- 1, constraint inheritance overflow, an embodiment of the open and closed principle.
- 2, strengthen the robustness of the program, at the same time change can also do very good compatibility, improve the maintenance of the program, scalability. Reduce risks introduced when requirements change.
7. Principle of synthesis/polymerization reuse
Try to use object composition (HAS-A)/ aggregation (Contanis-A) instead of inheritance to achieve the purpose of software reuse.
In other words, you use some existing objects in a new object, making them part of the new object, and the new object uses these objects to delegate to the purpose of reusing existing functions.
This principle can make the system more flexible and reduce the degree of coupling between classes, so that changes in one class have relatively little impact on other classes.
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: Page layer, interacting with the user, displaying the page to the user, feedback user behavior.
- ViewController: Logical layer that updates data, or pages, and handles business logic.
MVC can help you separate data, pages, and logical code. Make each layer relatively independent. This allows you to take some of the reusable functionality out of the way and simplify it. However, once the interaction of your App gets complicated, you’ll find that the ViewController becomes bloated. A lot of code is added to the controller, overloading the controller.
Here in particular: if only in order to solve the VC code bloated short board, the VC logical code according to the functional module using ** classification (category) ** split, only retain the necessary call interface can effectively reduce the VC code bloated problem.
As a developer, it is especially important to have a learning atmosphere and a communication circle. This is my iOS communication circle: no matter you are white or big, welcome to enter!! Topics to be shared include interview resource guides, reverse security, algorithms, architecture design, multi-threading, network advancements, also underlying, audio and video, Flutter and more……
According to the network to comb their own development experience summary of learning methods, free to share with you. You can download it yourself if you need to. + skirt: 196800191, or + WX (XiAZHiGardenia) Get interview materials resume templates together to communicate technical resource collections
Iii. MVVM architecture
MVVM is short for Model-View-ViewModel. It is a new architecture framework developed from the application mode combining MVP (Model-View-Presenter) mode and WPF.
MVVM layer frame results are as follows:
- Model: Data layer, read and write data, save App state.
- View: Page layer that provides user input behavior and displays output status.
- ViewModel logic layer, which translates user input behavior into output state.
- ViewController: Is responsible for data binding.
The mVVM-C architecture is more appropriate.
The ViewModel is the logical layer, and the controller is only responsible for data binding. This takes a lot of the burden off the controller. And the ViewModel is independent of the controller and the page. Then you can use it across platforms. You can also easily test it.
The MVVM pattern uses the data binding infrastructure, which is the core of the MVVM design pattern. In the use of bidirectional binding technology, the ViewModel will update automatically when the Model changes, and the View will change automatically when the ViewModel changes. The ViewModel contains all the interfaces and properties that are specific to the UI, and it has a binding property of the ViewModel’s View. When the binding property changes, the View automatically updates the View, so you can put the logic to update the View into the ViewModel, reducing the code for the Controller. IOS implements this binding using notifications and KVO.
The ViewModel is essentially a black box that takes input and processes it with internal business logic to produce results.
[image upload failed…(image-da16ad-1607776281959)]
Four,
This paper mainly introduces seven principles of software architecture, MVC architecture mode and MVVM architecture mode.
No matter what architectural pattern we choose, we are working toward code that is extensible, maintainable, reusable, and readable. The ultimate goal is to reduce the coupling of the code for subsequent modification, extension, and maintenance.
The biggest characteristic of MVVM mode and MVC mode is not to reduce the bloated code in VC, but the MVMM architecture mode unified the business logic in VM processing, convenient unit testing and automatic testing.
In the actual development, we must choose the architectural mode according to our actual situation. We should not blindly pursue innovation. The architectural mode suitable for our current business is a good architectural mode.
The above is just my opinion, if you have different opinions, please feel free to comment.
Refer to the reference
Seven principles of Software Architecture
Introduction to MVVM in RxSwift