Fishigui system Architecture analysis and Hierarchy II

Types of Fishigui

Fishigui is a framework system that provides graphical interface services for applications that do not interact directly with the end user (which is responsible for the application developed on the Fishigui basis to interact with the end user), but instead accept the hardware messages from the operating system, and when the corresponding processing is done, The drawing message is then sent to the graphical interface of the operating system, so Fishigui is a system-type software

Layer Architecture:

Layer architecture helps to build such an application: it can be decomposed into self-task groups, where each sub-task group is at a specific level of abstraction, hierarchical patterns are organized hierarchically, each layer serves the previous tier, and uses the functionality provided by the next layer. This pattern allows for a gradual layering of complex problems. Each layer in the hierarchy mode affects a maximum of two layers, so as long as the same interface is provided to the adjacent layer, each layer is implemented in different ways, and the software reuse can be fully supported.

A typical application of layered mode is layered communication protocols, such as the Iso/osi seven-tier network model.

Hierarchical architecture also decomposes software systems by object and class, not by function.

Design Requirements:

• The coupling between layers and layers should be as loose as possible, so that the specific implementation of a layer can easily be extended and replaced as long as the interface is guaranteed to be consistent.
• Same level, elements with similar responsibilities should be organized into the same layer
• Complex modules should continue to be decomposed into finer-grained layers or subsystems
• You should try to encapsulate the elements that are likely to change in one layer, so that when changes occur, we just change the affected layers.
• Each layer should call only the functional services provided by the next layer, but not across tiers, but for small systems that are not too restrictive, we can handle them flexibly, depending on the situation.
• Each layer cannot use the functional services provided by the previous layer, that is, it must not be a two-way dependency or a circular reference between layers and layers

• Avoid loop-dependent methods : You can extract the public part from the above layer to form a new layer for the following layers to invoke, or use special design patterns such as observer patterns

Fishigui system Architecture analysis and Hierarchy II