Brew-based loose coupling design III-design principles for portable and reusable software

 

Based onBrewLoose coupling design of the platformIII-Design Principles for portable and reusable software

Mao Xiaodong 2007-10-26

 

I,Overview:

This article mainly describes the most common design principles for portable/Reusable Software Based on the Brew platform, so as to take advantage of the BREW Platform's own advantages and accelerate development.

 

II,Design principles between high and low layers (Application and underlying implementation) components:

 

 

 

The design principles between high-and low-layer components are summarized as follows:

High-level components depend on interface abstraction and are independent from low-level implementation.

Low-level implementation relies on interface abstraction and does not rely on high-level components.

In essence, it is necessary to decouple high-level components from low-level components, and abstract and link them together through interfaces. Each part can be changed separately. Such changes are encapsulated, an abstract (Interface) that does not change externally ). This allows the two to change independently without affecting each other when the system (requirement) changes, so as to achieve portability, reusability, and scalability.

 

This principle corresponds to brew, which requires the app to only allow access to all services (implementations) through interfaces ). That is, an app is a high-level component that accesses underlying services through brew interfaces (standard or extended. Isolate coupling through interfaces.

 

In brew, a high-level component depends on a lower-layer component. Typically, an app bypasses the interface abstraction and directly calls the underlying implementation (in the form of a function or global variable ). The lower-layer components depend on the higher-level components. Typically, the internal implementation of the interface directly references the class members of the app or directly sends events to the app with a specific clsid.

The direct consequence of this kind of violation is that there is no isolation coupling, and no isolation/encapsulation change points, which leads to reusable and portable in the face of demand changes, low scalability. For upper-layer applications, changes may occur as customer needs change. This is a change point and needs to be encapsulated. The underlying implementation may also change with the differences between hardware and platform. This is another change point and needs to be encapsulated. In this case, we need to introduce an interface abstraction layer to isolate and encapsulate change points. This ensures the portability of high-level components (Apps) and low-level components (underlying implementation), because they all depend on interface abstraction. Typically, in a new project, the upper-layer UI can be transplanted directly. For the underlying implementation, you only need to ensure that the abstract of the interface on which the dependency is located remains unchanged. This step (the underlying implementation) can be synchronized with the UI.

On the other hand, it will bring a considerable additional burden! As time advances and changes increase, the burden will increase.

 

 

 

 

III,Design principles for High-level (Application room:

 

 

 

 

The design principles at the high level should be:

Decoupling communication between high-level components using a set of protocols to Delay Binding to runtime. Corresponding to brew, the high-level component here is obviously the app. The protocol here can be the Extended Interface exposed by the module, MIME type, and other means that can be used to decouple the interaction between BREW apps.

The benefit of this design principle is that the services provided by each application and the services requested from the outside are defined through a set of conventions, thus avoiding direct interaction between components.

 

The typical purpose of this design principle is to port or replace the upgrade of an app. You only need to implement all the necessary specifications for the upgraded application, and other applications do not need to make any changes.

Note: If you can find a better solution than an event, try not to use the event.

 

IV,Summary:

Based on the principles mentioned in this article, we can abstract a system. The most important thing is the inter-group (Inter-Application) protocol, and dependency abstraction (interfaces) between a group of high/low-level components ). At this time, whether it is porting the entire platform, or upgrading an application or underlying implementation independently, it becomes simple and controllable.

 

Appendix:

The interface referred to in this article is a type of object, specific to the language level, is the pure virtual base class in C ++, the interface in Java/C #, or the virtual table in C. During the compilation period, it indicates abstraction. binding implementation during the runtime is by no means simple (global, static) Functions and (global, static) variables.