Protocol oriented general component programming


Problems to be solved in previous projects:

I The VC in the live broadcasting room has more than 20000 lines of code, and the decoupling problem; The existing problems are as follows:

1. all sub modules are held by VC in the form of attributes

2. after each sub module loads and processes the data, it calls back the results to the VC through the agent

3. UI events generated by sub modules (except the function of triggering public components) need to trigger the logic of other sub modules of the live studio VC, and they are also imported to the VC through proxy callback.

These three situations are the root causes of the unlimited expansion of VC code in the current live broadcasting room.

Solution: adopt protocol oriented programming to decouple and establish a component tree with tree structure.

1. the parent component uses the subcomponent structure to combine sub component modules, so that each sub module does not have to declare an attribute.

2. each sub component is exposed to other components in the component tree in the form of protocol, and can complete its own functions.

3. each subcomponent can find the component component of any specified protocol in the component tree through parentcomponentforprotocol and subcomponentforprotocol. In this way, even if each sub component needs to communicate with other component modules of the VC in the live room, it can be directly completed internally without any code callback to the VC in the live room.

4. because each component exposes its functions in the form of protocols, these protocols can be abstracted into a basic framework pod library, which perfectly solves the dependency between sub components.

II Targetaction used in project Modularization:(in contrast, as a module decoupling scheme, ctmediator has some problems worth discussing.)

 1)CTMediatorUsing the runtime method, dynamically generating class and method selectors leads to type uncertainty. Methods and parameters are completely determined by strings and param dictionaries. The readability of the method itself is very poor and the reader is confused.

2) It is impossible to dynamically implement sub module route nesting and memory dynamic loading and dynamic release of sub routes


Protocol oriented general component programming

From the point of view of the author’s solution, they all feel troublesome. This categorypod is the protocol file provided by the independent function component module. Why not use the protocol directly.

III Solve the problem of the overflow of simple interest, which cannot be recovered

At present, the Componentization of different modules of the project (such as login module, recharge module, etc.) is realized by simple interest; But the problem of simple interest is that there is no dynamic memory load / release. If the login component is made, the recharge component can be implemented as a child component of the entire app root node. When a memory warning is received, the login succeeds or the recharge is completed. Release these child components.

IV Unit testing is more convenient

V After the code structure is clear, the bugs will be greatly reduced

Protocol oriented general component programming

Protocol oriented general component programming

Recommended Today

Spring JDBC usage steps

Spring JDBC usage steps *It is a simple JDBC encapsulation of the spring box, providing a JDBCTemplate object to simplify the development of JDBC *step: 1. Import the package commons-logging-1.2.jar spring-beans-5.0.0.RELEASE.jar spring-core-5.0.0.RELEASE.jaar spring-jdbc-5.0.RELEASE.jar spring-tx-5.0.0.RELEASE.jar 2. Create a Jdbc Template object, depending on the data source DataSource *Jdbc Template template=new Jdbc Template(DataSource datasource) 3. Call the […]