Quote:
In A software project if you have A,B,C… Different business modules. In the absence of a good architectural design, the coupling between different modules and the project will become higher and higher as requirements are iterated. Taking the IOS platform as an example, this paper proposes an architecture design scheme to realize non-intrusive add/delete service module. Some of these ideas and solutions are also available on other platforms.
Architecture design
We think about architecture design from two perspectives: [vertical] and [horizontal], as shown below:
Vertical – layered universal ability to sink
Sort out the common dependencies of each business, and sink the common capabilities used by each business, such as network, storage, cache, log, Crash stack, user behavior collection and so on. The business can be unidirectional dependent on the sinking module of the underlying support layer. The basic support layer can be further subdivided. Since this paper mainly discusses the decoupling design of the business module layer, it is not expanded here.
Level – Decoupled Event communication
Module A B… N can call each other. An application can remove a module at will, and ensure that the application is still running (it just doesn’t have the service to remove it).
Option 1. Protocol oriented programming
Interface – oriented protocol programming, business abstract interface definition is more clear. For example, if A module A wants to be replaced with A new module AA, the caller (user) can replace it painlessly without modifying the code as long as the interface is consistent. But protocols are still abstract dependencies, and cross-dependencies cannot be avoided. When we change the name of the interface or want to remove a module completely, we need the caller to cooperate with the change. If the code is spread across different business teams, the cost of dealing with compile dependency lights can become high due to coordinated changes across departments.
Option 2. Use event to further decouple through intermediaries
- Mediation objects store roles and behaviors:
- Event, the defined Event Key
- Subscribe to Target to dynamically create different business entity objects
- Response method Action, method call
- Business module roles and behaviors:
- Subscribe to Event subscribeEvent for other modules
- Event dispatchEvent dispatchEvent
- Handles its own business logic handleEvent
Understanding is achieved by relying only on Event objects without introducing specific business header files.
- Use the config file to add or delete services
The intermediary iterates through the config file during initialization to create an entry object for the business. Adding and deleting configuration files can realize dynamic adding and deleting of modules. Since we created the business entity class through the Runtime mechanism, even removing the business will not cause a compilation error
other
- Dependency and load order issues
It can be specified in the configuration file and loaded in queue order by code.
- Performance tip
Do not perform time-consuming operations during initialization to avoid occupying too much memory and affecting the cold startup speed of applications. It is recommended to use lazyLoad to load business objects that are really resource-consuming.
- About Protocol Programming
Even with events we need to abstract some behavior into protocol interfaces. The difference is that the protocol at this time is not the definition of a specific business protocol, but the definition of general behavior such as event distribution loading state.