Github github.com/beyondxia/m…

Traditional componentization schemes are introduced

The core problem of componentization is decoupling between components, and decoupling inevitably faces to solve the communication problem between components, namely communication mechanism. According to the dimension of communication mechanism, it can be roughly divided into the following two schemes: protocol communication and interface communication. The basic realization principle of both is as follows.

1. Protocol communication

The typical protocol communication mode is to use Scheme to communicate. This approach minimizes dependencies between components, or even allows for complete isolation. Its core idea is: data transfer between components in accordance with a specific communication protocol, the bottom of the framework through reflection of the way to call the service method, so as to achieve communication between components.

2. Interface communication

The protocol communication design we introduced above is protocol + reflection. Due to the natural problems caused by reflection, such as performance, confusion, code readability, service changes are not aware to callers, we prefer the implementation of interface sinking.

So what is interface communication? Interface communication means data communication between modules through the way of interface sinking mentioned above. Our framework also carries out interaction between components based on this way, and the specific methods are as follows:

  1. A component needs to expose its services by providing one or more intermediate interface files that contain the specific methods that the component needs to expose.
public interface ITrainTicketService {
    String SERVICE_NAME = FFServiceConstants.SERVICE_TRAIN_TICKET;
    TrainTicketNavigator navigator();
    void registerJSHandlers(IBridgeFragment fragment);
    int getTicketCount();
}
Copy the code
  1. To avoid direct coupling dependencies between components, all exposed interfaces and some shared classes need to sink into the service layer below the business. The host project needs to provide such a public directory or public module to hold the class files associated with the exposed service.

  1. Register service: Invoke the registration service method provided by the framework to register the implementation class of this component in the framework for other components to call.
  2. Service invocation: by calling the specific method provided by the framework, we can get the instance of the intermediate interface of the called component. This interface contains all the service methods exposed by the called component, so the instance of this interface can be invoked to realize the service invocation of the called component.

Advantages and disadvantages of traditional componentization

The shortcomings of protocol communication have been briefly explained in the above, and the advantages and disadvantages of interface communication mechanism are mainly analyzed here. Advantages:

  1. Changes to component services are aware to callers. If there are upgrades or changes to the services provided by the component, the caller is aware of them at the compiler, avoiding the problem being exposed at run time.
  2. The invocation of a service does not rely on reflection, so there are no performance, confusion, or readability problems compared to the communication mechanism of the component bus. Inadequate:
  3. A common directory or common module needs to be provided as the service layer, and all interface files and intermediate shared files need to be manually copied to the service layer.
  4. If a component needs to provide services, in addition to its implementation class, it needs to provide one or more intermediate interface files, which increases the development amount, component integration complexity and maintenance cost.
  5. Some of the intermediate classes associated with the interface, especially Model, also need to be moved synchronously to the public directory.
  6. Because the service implementation class has a dependency on the service interface, the business side needs to implement the exposed interface and implement the specific business functions that need to be exposed.
  7. Registration of all component services needs to be done manually, increasing development effort and risk.

For these problems, our Modules framework provides corresponding solutions, as detailed in the next article

Several considerations for the componentization of a less invasive componentization scheme

Next: A simple and less invasive componentization scheme