Fishgui: Composite Mode

Questions:

Figure 11-1 and figure 11-2 are shown in the object graph of Http://blog.csdn.net/u012829152/article/details/42172233;11-1, Fishgui objects related to window elements within the system, At some point in the system, a three-layer attribute structure is formed, and the containment relationship between the objects is shown, whereas in the design model the class associated with the window element in Figure 11-2, all the classes constitute another tree-like inheritance structure, the two tree structures are not exactly the same, such as the number of different levels, The location of the particular class and its corresponding object instances is inconsistent, and if the design model does not reflect these differences, the programmer must handle the differences in the code itself, inevitably leading to a disjointed design and coding, affecting the final quality of the system.

In order to fully embody the containment relationship between classes in the class diagram associated with the window element, it is necessary to add the relationship between the classes based on the original class inheritance tree, and to supplement the class relationships, i.e. how to express the inheritance in a unified class diagram and include the two logical relationships Fishgui

Composite Mode

design intent: When an object in a system needs to be combined into a tree structure To represent the overall and partial hierarchical relationships, you can use compound mode. In the inheritance tree of a composite pattern, a subset of derived classes are simply aggregated objects in aggregate and partial aggregations, which can no longer aggregate other objects, while the other part aggregates object instances of any non-abstract class in the inheritance tree. The composite mode can access the object instances of all classes in the inheritance tree by inheriting the tree, making the client program transparent and uniform, and for the client, there is no difference between the simple aggregated objects in the pattern and the conforming objects that can aggregate other objects. The unity of the inheritance relationship and the usefulness of the aggregation relationship are best combined

basic structure: The key to implementing pattern is to create an abstract class to represent all simple objects and compound objects. To make them public, simple objects and composite objects in the system are derived classes of this abstract class

Parts (Component) classes: An abstract class for the entire inheritance tree, Defines the interfaces for all classes in the entire tree, including the interface for managing and accessing the aggregated parts, where you can implement some default behavior, and sometimes you need to define methods to access the upper parts, which makes it more efficient to traverse the entire object Tree

leaf Category: The leaves in the whole tree are missing, and the leaf parts are not internally aggregated. In a leaf part, we can define the behavior of a simple object

compound (Composite) class: Represents a composite part in an entire tree, and a composite part defines the behavior of a composite object. This includes the way to manage and access the interfaces of the aggregated parts. Composite parts also need to be concerned about how multiple aggregated parts are stored

client programs generally access the entire inheritance tree through the interface of the part class

Transparent composite pattern implementation: Each compound class can aggregate any kind of leaf class or compound class object instance, forms the recursive compound structure; In order for the client program to have transparent access to all objects, the abstract class component must define the methods required for all derived classes. This includes methods related to aggregation relationships, as well as methods common to simple objects and composite objects, which are often preferred for fewer classes of inheritance. But the allocation of responsibility for such schemes is not clear.

：

Secure Composite Mode implementation : Strictly restricts the kinds of objects that each compound class can aggregate, and ensures the clarity of class responsibilities. In this implementation, no transparent access is provided, and the client program needs to perform related operations through each specific derived class interface. The object pointers returned from the compound class must be required by the customer, so there is no need to force type conversions. The flaw is that each compound class can aggregate the kinds of objects are limited, it is difficult to implement code reuse, in addition to the client program in the call compound object or leaf object related interface is, the operation process is very cumbersome

Fishgui: Composite Mode