Chapter 4 Structure Model Structure Models involves how to combine classes and objects to achieve a larger structure. The structural class mode uses the inheritance mechanism to combine the interface or implementation. A simple example is a multi-inheritance method combining more than two classes into a class, and the class contains the nature of all parent classes. This model especially contributes to multiple independently developed class libraries work together. Another example is the form of A D A P T E R (4. 1) mode. In general, the adapter makes an interface (the interface of A D A P T E E) is compatible with other interfaces, thereby giving a unified abstraction of multiple different interfaces. To do this, the class adapter is privately inherited by a A D A P T E-class. Thus, the adapter can represent its interface with the interface of A D A P T E E. The structural object mode is not a combination of interfaces and implementations, but describes how to combine some objects to achieve new features. Since the object portfolio can be changed at runtime, the object combination has greater flexibility, and this mechanism is unlikely to be implemented. Composite (4.3) mode is an instance of structural object mode. It describes how to construct a class level structure, which consists of two types of objects (primitive objects, and combined objects). The combined objects allow you to combine primitive objects and other combination objects. Thereby, thereby forming any complicated structure. In Proxy (4.7) mode, the P R O X Y object is a convenient alternative or placeholder of other objects. It can have a variety of forms. For example, it can represent objects in a remote address space in a local space, or represent a larger object that requires load, can also be used to protect access to sensitive objects. P R O X Y mode also provides indirect access to some unique nature of the object, so that it can limit, enhance or modify these properties. F L Y W E I G H T (4. 6) mode For the shared object defines a structure. At least two reasons require object sharing: efficiency and consistency. F L Y W E I G H T 's Object Sharing Mechanism mainly emphasizes the spatial efficiency of the object. Applications using many objects must consider the overhead of each object. Use object sharing instead of object replication, you can save a lot of space resources. However, only when these objects are not defined as the context-related state, they can be shared. The object of F L Y W E G H t does not have this state. Other information needed when performing tasks are only transferred when needed. Since there is no state associated with the context, the F L Y W E I G H T object can be freely shared. If F L Y W E I G H T mode illustrates how many smaller objects are generated, then F A C A D e (4. 5) mode describes how to represent the entire subsystem with a single object. The F a c a d e in the mode is used to represent a set of objects, and the role of F A c a d e is to forward messages to the object it represent. B R I D G E (4. 2) Mode separates abstraction and its performance of the object, so that they can be altered independently. D E C O R A T O R (4. 4) Mode describes how to dynamically add responsibilities to objects. D E C O R A T O R Mode is a structural pattern. This mode uses a recursive way to combine objects, allowing you to add any more object responsibilities. For example, a D e c O R A T O R object containing a user interface component can add a decorative of a border or shadow to the component, or it can scroll and scramble the window and scaled in such a function added. We can nested a D e C O R A T O R object in another object, you can simply add two decorations, and add other decorations. Therefore, each D e C O R A T O R object must be compatible with the interface of its components and to ensure that messages are delivered to it. D E C O R A T O R Mode can complete its work (such as a border of the component) before or after forwarding a message. Many structural patterns have a certain degree of correlation and we will discuss these relationships at the end of this chapter.
4.1 Adapter - Class Object Structure Type 1. It is intended to convert a class interface into another interface that customers want. A D A P T E R Mode allows you to work with those classes that are not compatible without compatibility. 2. The alias wrapper WR a p p e r. 3. Motivation Sometimes, toolbox classes designed for multiplexing cannot be reused because its interface does not match the interface required by the professional application field. For example, there is a drawing editor that allows users to draw and arrange basic primitives (lines, polygonal and body, etc.) to generate pictures and charts. The key abstraction of this drawing editor is a graphic object. The graphic object has an editable shape and can draw itself. The interface of the graphic object is defined by an abstract class called S H A P E. The drawing editor defines a subclass of S H A P E for each graphic object: L i n e s H A P e Class corresponds to the straight line, and P O L Y G O N S H A P E class corresponds to a polygonal type, and the like. The class relatively easy to implement like L i N e S H a P e and P O L Y G O N S H A P E, because their drawings and editing functions are very limited. However, for TE X T S H a P E subclasses that can be displayed and edited, it is difficult because even basic body editing should also involve complex screen refresh and buffer management. At the same time, the user interface toolbox for finished products may have provided a complex TE X T VI E W class for display and editing the body. Ideally, we can reuse this TE X T Vi E W class to achieve TE X T S H a P E class, but the toolbox's designer does not consider the presence of S H a p e, so TE X T Vi E W and S H A P E objects cannot be interchangeable. An application may have some classes that have different interfaces and these interfaces are not compatible with each other, and how does TE X T VI E W have existed and unrelated classes work? We can change the TE X T VI E W class to make it compatible with the interface of the S H a P E class, but premise must have the source code of this toolbox. However, even if we get these source code, there is no significance of modifying TE x T Vi E W; because it should not be used to implement an application, the toolbox has to use some interfaces related to specific areas. We can define a TE X T S H A P-class without the above method, which is adapted to adapt the interface of the TE X T VI E W and the interface of S H A P e. We can do this in two ways: 1) Inheriting the interface of the S HAPE class and the implementation of TE XT VI EW, or 2) uses a TE XT VI EW as part of the TE XT S Hape and uses TE XT The interface of VI EW implements TE XT S Hape. Both methods correspond to the class and object version of the A D A P T E R mode. We call TE X T S H A P E as the adapter A D A P t e R. 9 2 Design mode: can be used for object-oriented software
The above class diagram illustrates an object adapter instance. It illustrates how the B O U N D I N G B O X declared in the S H A P E class requests how to be converted into G e t e x t e n t in the TE X T VI E W class. Since TE X T S H A P E matches the interface of TE X T Vi E W with the interface of S H A P e, the drawing editor can be multiplexed as the originally incompatible TE X T Vi E W class. A D A P T E R is often responsible for providing the functions that are not provided by the matching classes, which illustrate how the adapter implements these responsibilities. Since the drawing editor allows the user to "drag" to a new location in TE X T Vi e W design in TE X T Vi e W design. We can implement the C R E A T E M A N I P U L A T OR operation of the TE X T S H A P E class, thereby increasing this missing function, returns an example of the corresponding M a N i P U L A T O R subclass. M a N i P U L A T O R is an abstract class that knows how the object knows how to drive the S H A P E response to the corresponding user input, such as dragging the graphic to a new location. Corresponding to a pattern of different shapes, M A N I P U L A T O R has different subclasses;, for example, subclass TE X T m a N I P U L A T O R corresponds to TE X T S H A P e. TE X T S H A P E increases the function of the lack of TE X T Vi E W by returning a TE X T m a N I P U L A T O R. 4. Applicability The following uses A D a P TEE R mode • You want to use an existing class, and its interface does not meet your needs. • You want to create a class that can be multiplexed, which can work with other unrelated classes or unpredictable classes (ie those that may not be compatible with those interfaces). • ((only for object a d a p t e r) You want to use some already existing subclasses, but it is impossible to make subcatetics for each one to match their interfaces. The object adapter can adapt its parent class interface. 5. The structural adapter uses multiple inherits to match another interface, as shown below. The object matching depends on the object combination, as shown in the following figure. 6. Participants • TA R G E T (S H A P E) - Defines the interface associated with the specific area using C L i e n T. • C L i E N t (D R A W I N g E D i T O r) Chapter 4 Structure Model 9 3
- Collaborate with an object that meets the TA RG E T interface. • A D A P TE E E (TE X T Vi E W) - Defines an existing interface that needs to be adapted. • A D A P T E R (TE X T S H A P E) - Adapted to the interface of A D A P TE E E to adapt 7. Collaboration • CLIENT calls some operations on the A D A P TE R instance. The adapter then invokes the operation of A D A P T E E to implement this request. 8. Effects adapters and object adapters have different trade-offs. Class adapter • Match A D A P T E E and TA RG E T in a specific A D A P TET. The result is that when we want to match a class and all its subclasses, class A d a p t er will not be competent. • Make A D A P T E R to redefine part of the line of A D A P T E E because A D A P TE R is a subclass of A D A P T E E. • Only an object is introduced, and an additional pointer does not require an additional pointer to obtain A D A P T E E. Object Adapters • Allow a A D A P TE E R to operate at the same time as A D A P t e-, and all of its subclasses (if some subclasses) are operated. A D A P TER can also add functions to all A D A P T E E once again. • Make the behavior of A D A P TE E E make it difficult. This requires the subclass of A D A P T E E and causes A D A P T E R to reference this subclass rather than reference A d a p t e it itself. Other factors that need to be considered when using A D A P TE E R mode: 1) Adapter's matching degree of matching the interface of the interface of A D A P T E E matches the interface of TA RG E T Mount each A d A P t e R may not be the same. The range of work may be, from a simple interface transition (such as changing the operand) to support a completely different set of operations. The workload of A D A P T E R depends on the similarity of the TA RG E T interface to the A D A P T E E interface. 2) Insertable Adapter When other classes use a class, if the required hypothesis is, this class is more reused. If you construct an interface match to a class, you don't need to assume that other classes are visible to an identical interface. That is, the interface matches allows us to add your own classes to some existing systems, and these systems may vary. O B J E C T - WO R K / S M A L T a L K [P A R 9 0] The word with the internal interface adapter is described using the word Pluggable Adapter. Considering the TR E E D I S P L A Y window assembly, it can graphically display the tree structure. If this is a special-purpose window component, it is only used in one app, which may ask the object it displays with a special interface, that is, the subclass of abstract class TR E E. If we want Tr E E D I S P L a y has good reuse (more, we want to use it as part of the available window component toolbox), then this requirement will be unreasonable. The app defines itself to the tree structure class, and should not be used to use our abstract class TR E E. Different tree structures have different interfaces. For example, in a directory hierarchical structure, an access subdirectory can be operated by G E E E S, however, in one inheritance hierarchy, the corresponding operation may be referred to as G e T S UB C L A S e s. Although the interfaces used by the two hierarchies are different, a multiplex TR E E D I S P L A Y window component must be able to display all of these two structures. That is, TR E E D I S P1 Y should have a function of interface adaptation.
We will implement a variety of ways to build interface adaptation in the class. 3) One potential problem with the use of bidirectional adapters to provide transparent operations is that they don't transparent to all customers. The adapted object is no longer compatible with the interface of A D A P T E E, which is not all the 9 4 design modes that all A D A P TEE EE objects can be used: can be used for object-oriented software. It can be used. The two-way adapter provides such transparency. Two different customers need to view the same object in different ways, the bidirectional adapter is especially useful. Consider a two-way adapter, it integrates the graphic framework UNIDRAW [VL90] and the constraint solve toolbox q o c a [h h M v 9 2]. Both systems have some classes, these classes explicitly represent variables: u N i d R A W contains class S t a t e Va R I a B L E, and Q O c A contains clarity C O N S T R A I N T Va R I A B L E, as shown below. In order to make U NiDRAW and QoCA work, you must first match class c onstraint va riable to class S Tate Va Riable; and to pass QoCA's solving results to u Nidraw, you must make S Tate Va Riable with C Onstraint Va Riable match. This solution includes a bidirectional adapter C O N S T R I A B L E, which is a subclass of C O N S T R A I N T Va R I A B L E and the class S t a t e Va R I a B L E, and C O N S T R I A B L E makes two interfaces match each other. Multiple inheritance in this example is a feasible solution because the interfaces are different from the adapted class. The two-way adapter is compatible with the two matched classes, which can work in both systems. 9. Realization Although the implementation of a dapter mode is usually simply straight, you still need to pay attention to the following questions: 1) When using C implementation adapter class When using C to implement the adapter class, a Dapter class should inherit TA. RG ET class, and inherit a Daptee class with a private manner. Therefore, the A D A P TET ER should be a subtype of TA RG E T, but is not a subtype of A D A P T E E. 2) Insertable adapters There are many ways to implement the pluggable adapter. For example, the TR EE D ISPLAY window assembly described above can automatically arrange and display layer-based structures, and there are three implementation methods: First (this is also all these three implementations) is to find a "narrow" for Adaptee. Interface, you can use the minimum operation set. Since the narrow interface containing less operation is relatively easy to match the wide interface containing more operations. For TR E E D I S P L A Y, the matched object can be any one of the layered structure. Therefore, the minimum interface set contains only two operations: an operation definition How to represent a node in the hierarchy, and the other operation returns the child node of the node. For this narrow interface, there are three implementations of implementation: a) Define the abstraction operation of the narrow A D A P t e-interface using abstract operation in the TR E E D I S P L A Y class. This enables these abstract operations and matches the object of the specific tree structure. For example, D i R e c t O R Y TR E E D I S P1 The Y Subclass will implement these operations by accessing the directory structure, as shown in the following figure. Chapter 4 Structure Model 9 5
(To the QoCA class hierarchy) (to Unidraw class hierarchy) D i r e c t o R Y TRE EE D I S P L A y is used to specify this narrow interface, so that its D i R E C T O R Y B R O W S E R can use it to display the directory structure. b) Using a proxy object In this method, TR E E D I S P L A Y forwards the request for the access tree structure to the agent object. TR E E D I S P L A Y 's selection and supplies these options to proxy objects so that customers can control adaptation, as shown below. For example, there is a D i R E C T O R Y B R O W S E R that uses Tr E E D I S P L A Y as front. D i R E C T O R Y B R O W S E R may construct a better agent for matching TR E E D I S P L A Y and Hierarchical Directory Structure. In the dynamic type language of S m a L t a l k or Objective C, this method only needs an interface to register the agent to the adapter. The Tr E E D I S P L A Y simply forwards the request to the proxy object. N e x T S t e p [a D D 9 4] A large number of uses this method is used to reduce subclasses. In the static type language of C , an agent is required for an explicit interface definition. We put the narrow interface required by Tr E E D I S P L A y in the pure virtual class TR E E E G A T E to designate such an interface. Then we can use the inheritance mechanism to integrate this interface to our choice - here we select D i R E C T O R Y B R O W S E R. If D i r e c t o R Y B R o W S e r does not have a parent class, we will use a single inheritance, otherwise it will adopt multiple inheritance. This method that fuses the class with respect to the introduction of a new TR E E D I S P L A y subcence and separately achieving its operations alone. c) The parameterized adapter typically supports the method of insertless adapters in S M A L t a Lk, and one or more modules are used to parameterize the adapter. Module constructs support for no subclassification. A module can match a request, and the adapter can store a module for each request. In this example, the TR E E D I S P L A Y stores a module to convert a node into a G R a P H i C N o D E, and another module is used to access the child node of a node. For example, when you establish TR EE D Isplay for a directory hierarchy: If you create an interface adaptation in a class, this method provides another option, which is more than the subclass of Easy. 10. Code Example Voltage Section An example, starting from class S H a P e and TE X T Vi E W, we will give the code adapter and object adapter implement code. 9 6 Design mode: can be used for object-oriented software
S h a p e assumes that there is a border that is defined by the two corners of it. TE X T VI E w is defined by the origin, width, and height. S H A P E also defines C R E A T E M A N I P U L A T O R Operation for creating a M a N i P U L A T O R object. When the user operates a graph, M a N i P U L A T O R object knows how to drive this graphic. TE x T Vi E w does not have the same operation. TE X T S H A P E class is an adapter between these different interfaces. The class adapter uses multiple inheritance adaptation interfaces. The key to the adapter is to inherit the interface with another branch inherited the implementation part of the interface. Usually this distinction in C is: inheriting the interface with a public manner; inheriting the implementation of the interface with a private manner. Below we define the TE X T S H a P e adapter in accordance with this conventional method. B O U N D I N G B O X Operates the interface of TE X T VI E W to match the interface of S H a P e. I S E MPTY operation gives a method commonly used in the adapter implementation: Direct forwarding request: Finally, we define c reate m Anipulator (TE XT VI EW does not support this operation), assuming that we have implemented TE XT SHAPE operation class TE xipulator. Chapter 4 Structure Model 9 7
C R e a t e m a n i p U L A T O R is an instance of Factory Method. The object adapter uses an object combination to combine a class with different interfaces. In this method, the adapter TE X T S H A P e maintains a pointer to TE X T Vi E W. TE X T S H A P E must initialize a pointer to the TE X T Vi E W instance in the constructor that is also required to call its TE X T Vi E W object when its own operation is called. In this example, it is assumed that the customer creates a TE XT VI EW object and passes it to the TE XT S Hape: c Reate M Anipulator's implementation code is the same as the implementation code of the class adapter version, because its implementation starts from scratch There is no multiple function of any TE XT VI EW. Comparing this code with the corresponding code of the class adapter, you can see that the write object adapter code is relatively trouble, but it is more flexible. For example, customers only pass an instance of the TE X T Vi E W subclass to the constructor of the TE x T S H A P E class, the object adapter version of TE X T S H A P e can also work well with TE X T Vi E W subclasses. 11. Examples of the application should be known from a drawing application ET D RAW based on ET [WGM 8 8], ET D RAW is multiplexed by using a TE XT S Hape adapter class. Some classes in ET and use them for editing of text. I NTER VI EW 2. 6 defines an abstract class I nteractor [VL 8 8] for user interface elements such as ScrollBars, Buttons and Menus, which is also defined for the structured graphic objects such as line, circle, polygon, and spline. An abstract class G Raphics. I N t e R a C T O R and G R a P H i c s has a graphical appearance, but they have different interfaces and implementations (they do not have the same parent class), so they are not compatible. In other words, you can't directly embed a structured graphic object 9 8 design mode: can be used for object-oriented software
A dialog box. And I N t e R VI E W 2. 6 defines a subject adapter called G R a P H i C B L O CK, which is a subclass of i N T E R A C T O R, including an example of G R a P H i C class. G R A P H i C K Matches the interface of the G R A P H i C to the interface of the I N T E R A C T O R. G R A P H i C K makes an example of a G R a P H i C to be displayed, scrolled, and scaled in the I n t e R A C t O R structure. The insertable adapter is very common in O b J E C T WO R K (P a R 9 0]. Standard S M a L t a l k defines a VA L u e m o D e L class for a view that displays a single value. To access this value, VA L u e m o D e l defines a "V A L u e" and "V A L u E:" interface. These are all abstract methods. The application uses the name associated with the specific area, such as "Width" and "Width:", but in order to match the name related to the VA LUE M ODEL, they do not have to generate va lue m. Odel's subclass. O B J E C T WO R K S / S M A L T A L K contains a subclass of VA L u e M O D e L, called P L u g g A B L E A D A P T O R. P L u g g A B L E A D A P T O r object can match other objects to the interface of VA L u e m o D e l ("V A L u e" and "V A L u E:"). It can be parameterized by modules to get and set the desired value. P L u g g A B L E A D A P T O R uses these modules inside to implement "V A L u e" and "V A L u E:" interface, as shown below. For syntax convenience, P L u G g A B L E A D A P t O r also allows you to transfer the name of the selector (for example, "W i D T H" and "W i D T H:"), which automatically converts these selectors to the corresponding modules. Another example from O B J E C T WO R K K is TA B L E A D A P T O R Class, which can match an object sequence to a table representation. This form displays an object per line. The message set that the client can use to use the message set to the TableAptor to set the line properties from an object. In N e x t A P P K i T [A D 9 4], some classes use the proxy object to match the interface. An example is class N x B R O W S E R, which shows a list of layered data. N x b R O W S e 用 Class with a proxy object access and adapt data. M a y e r "Marriage of Convenience" [ME 8 8] is a form of adapter. M a y e r describes how F i X E D S t a c k class matches an implementation portion of a A R R A Y class and an interface portion of a S t a c k class. The result is a stack containing a certain number of items. 12. The structure of the correlation mode B Ridge (4. 2) is similar to the object adapter, but the starting point of the B Ridge mode is different: B Ridge purpose is to separate the interface part and the implementation part, thus can be more easily and independent of them. change. A D A P TER is meant to change an interface of an object. D E C O R A T O R (4. 4) The mode enhances the functionality of other objects and does not change its interface.
Therefore, DE C O R A T O R is better than the application of the application than the adapter. The result is that D E C O R A T O R supports recursive combinations, and pure use of adapters is impossible to achieve this. Mode P R O X Y (4. 7) Define a proxy for another object under conditions that do not change its interface. Chapter 4 Structure Model 9 94.2 Bridge (Bridge) - Object Structure Type 1. It is intended to separate the abstraction section to its implementation, so that they can be independently changed. 2. Alias H A N D L E / B O D Y3. Motivation When an abstract may have multiple implementations, it usually uses inheritance to coordinate them. Abstract class defines the abstract interface, and the specific subclass is implemented in different ways. But this method is sometimes not flexible enough. The inheritance mechanism secures the abstraction section to its implementation portion, making it difficult to modify, expand, and reuse the abstract parts and achieve parts. Let us consider the implementation of a portable Wi N D O W abstraction in a user interface toolbox. For example, this abstract portion should allow users to develop some applications that can be used in the X WINDOW SYSTEM and IB M systems. Using the inheritance mechanism, we can define Wi N D O W Abbreviations and its two subclass XWI N D O W and P M Wi N D O W, which implements the Wi N D O W interface on different system platforms, respectively. But inheritance mechanisms have two deficiencies: 1) Extending Wi N D O W Abstract It is not convenient to apply for different types of windows or new system platforms. It is assumed to have a subclass I C O N Wi N D O W for Wi N D O W, which is specifically used to abstract Wi N D O W to be used for icon processing. In order to support the i con wi ndow support two system platforms, we must implement two new types of XI CON WI NDOW and PMI Con Wi ndow, and we have to define two classes for each type of window. . In order to support the third system platform, we must define a new Wi N D O W subclass for each window, as shown in the following figure. 2) The inheritance mechanism allows the customer code to be related to the platform. Whenever a customer creates a window, you must instantiate a specific class that has a specific implementation section. For example, creating a X W i N D O W object Binds Wi N D O W Abbreviation to the implementation part of X Wi N D O W, which makes the client dependent on the implementation of X Wi N D O W. This will make it difficult to transplant customer code to other platforms. Customers should not involve their specific implementation portions when creating a window. It is just a platform for the implementation of the window depends on the platform running. This customer code should not involve specific platforms when creating a window. B R I D GE mode Solve the method of the above problem is that Wi N D O W abstraction and its implementation portions are placed in separate class hierarchies. One of the class hierarchies is directed to the window interface (Wi NDOW, I Con Wi NDOW, TR ANSIT WI NDOW), and another independent class hierarchy implementation part of the platform-related window, the root of this class hierarchy is Wi NDOW I MP . For example, X W i N D O W I m p subcategories provide an implementation based on X Wi N D O W systems, as shown in the following page. All operations for Wi N D O W subclasses are implemented in an abstract operation in the Wi N D O W i m P interface. This separates the abstraction of the window from the system platform. Therefore, we refer to the relationship between Wi N D O W and Wi N D O W I m P, as it plays a bridge between abstract classes and its implementation, so that they can change independently. 1 0 0 Design mode: can be used for object-oriented software
4. Applicability The following uses B R i D g E mode: • You don't want to have a fixed binding relationship between abstract and its implementation. For example, this may be because the part should be selected or switched at the program runtime. • Abstractions of classes and its implementation should be able to expand by the method of generating subclasses. At this time, B R I D GE mode allows you to combine different abstract interfaces and implementations and expand them separately. • Modifications to an abstract implementation should have no impact on the customer, that is, the customer's code does not have to recompile. • (C ) You want to completely hide the abstract implementation part of the customer. In C , the class represents is visible in the class interface. • As shown in the first class diagram intended in the first class map, there are many classes to be generated. Such a class hierarchy indicates that you must decompose an object into two parts. R u m b A u g h refers to this type of hierarchy as "Nested Generalization). • You want to share implementations between multiple objects (possibly using reference counts), but at the same time as you don't know this. A simple example is the S t R I n g class [C O P 9 2] of C O P L I e n, and multiple objects in this class can share the same string representation (S T R I N G R E P). 5. Structure Chapter 4 Structured Model 1 0 1
6. Participants • Abstract (Wi N D O W) - Define the interface of the abstract class. - Maintain a pointer to the I m P L E M E N T O R type object. • RefinedabStraction (Iconwi N D O W) - Expanded the interface defined by the A B S T R A C T I O N. • Implementor (Wi N D O W I M P) - Defines the interface of the implementation class, which is not necessarily consistent with the interface of the A b S T R A C T I O N; in fact these two interfaces can be completely different. In general, the I m P L e m e n t O R interface only provides basic operation, and A B S T R A C T I O N defines a higher level of operation based on these basic operations. • ConcreteImplementor (XWindowImp, PMWI N D O W I M P) - Implementing the I M P L E M E N t O R Interface and defines the specific implementation thereof. 7. Collaboration • Abstract The request forwarding the request of C L i e n to its I m P L e m e n t o R object. 8. Effects B R I D GE mode has some of the following advantages: 1) Separation interface and its implementation of one implementation may not be bound to an interface. The implementation of abstract classes can be configured at runtime, and an object can even change its implementation at runtime. Separation of A B S T R A C T I O N and I M P L E M E N T O R Helps Reduce Depending on Partial Compile Time, when changing an implementation class, does not need to recompile A B S T R A C Ti N-class and its client program. In order to ensure binary compatibility between the different versions of the library, there must be this nature. Further, the interface is separated from the implementation to a hierarchical, thereby producing a better structured system, and the high-level portion of the system only needs to know that A b S T R A C T I O N and I M P L E M E N T O R can. 2) Improve the expandability You can expand independently of the hierarchy of A b S T R a C T I O N and I M P L E M E N TO. 3) Implementation details Transparent to our clients You can hide your customers, such as sharing I m P L E N t O R objects, and corresponding reference counting mechanisms (if any). 9. Realize the following problems when using B R i D g E mode: 1) Only one Implementor does not need to create an abstract I m P L e m e n t O R class when there is only one implementation. This is the degradation of the B R I D g E mode; there is a one-to-one relationship between A B S T R a C T I O N and I M P L E M E N t O R. Despite this, when you want to change a class's implementation does not affect the existing customer programs, the pattern separation mechanism is still very useful - that is, do not have to recompile them, just reconnect. C a R O L a N [C A R 8 9] This separation mechanism is described with "Cheshire Cat". In C , the class interface of the I m P L e m e n t o R class can be defined in a private header file, which is not available to the customer. This way you completely hide a class of implementation of the customer.
2) Creating the correct I m P L E M e N t O R Object When there is a plurality of I M P L E M E N t o r, what method you should use, where is it to determine which I m p L E M e n t o? If the A b S T R A C T I O N knows all C O N C R E TET E I M P L E M E N T O R Class, it can instantiate one of its classes in its constructor, which can determine which type of instantiation is determined by passing to the constructor. For example, if a 1 0 2 design mode: can be multiplexed-oriented software-oriented software-oriented software-oriented software, which can determine which type of instantiation according to the size of C O L E C T I O N. The implementation of the linked list can be used for smaller C O L E C T I O N, and the H A S H can be used for larger C O L E C T I O N. Another method is to first select a default implementation and then change this implementation as needed. For example, if the size of a C O L E C T I O N exceeds a certain threshold, it will switch its implementation, making it more suitable for C O L E C T I O N. It is also possible to give another object, which is determined once. In the example of Wi N D O W / Wi N D O W I MP, we can introduce a F A C t O R Y object (see Abstract Factory (3.1)), the only responsibility of the object is the details of the package system platform. This object knows how to create a type Wi N D O W i m P object that should be created for the platform used; Wi N D O W requires only a Wi N D O W i m P to it, and it returns the correct type of Wi N D O W i m p object. The advantage of this approach is that the Abstract class is not directly coupled to any I m P L E M e n T O R class. 3) Sharing I M P L E M e N T O R Object C O P L i E N illustrates how to share some implementations between multiple objects in multiple objects with H a N D L E / B O D Y method commonly used in C . [C O P 9 2]. Where B O D Y has an object reference counter, H A N D L E adds and decreases it. The code to which the shared program is assigned to the handle is generally provided: 4) Use multiple inheritance mechanisms to combine the abstract interface and its implementation portion in C [M A R 9 1]. For example, a class can inherit the A b S T R A C T I O N to inherit the C O N C R E TE E I M P L E M E N TE E N R. However, since this method relies on static inheritance, it will achieve a partial and interface that fixed constant. Therefore, it is impossible to use multiple inheritance methods to achieve true B R I D g E mode - at least C is not available. 10. Code Example The following C code implements examples of Wi N D O W / Wi N D w O I M P in the section, where Wi N D O W Class is defined by the client application: Chapter 4 Structure mode 1 0 3
Wi N D O W maintains a reference to Wi N D O W i MP, Wi N D O W I M P abstract class defines an interface to the underlying window system. Subclasses of Wi N D O W define different types of windows that can be used in applications, such as application windows, icons, dialogs Temporary windows, and mobile panels of the toolbox, and more. For example, a PPLICATION WI NDOW class will implement D RAW C onTents to draw the VI EW instance it stored: i Con Wi NDOW stores the bitmap name corresponding to the icon it appears.. .. .. and implement D RAW C ontents Operation This bit is drawn on the window: 1 0 4 Design mode: Subject to object-oriented software We can also define many other types of Window classes, such as Tr Ansient Wi NDOW by one window when talking to customer Create, it may be to communicate with this window that creates it; P alette Window is always above other windows; i Con D Ock Wi NDOW has some i con wi ndow, and it is responsible for arranging them neatly. The operation of Wi N D O W is defined by the interface of Wi N D O W I M P. For example, before calling the Wi NDOW I MP Operation Draw a rectangle in the window, D RAW R ECT must extract four coordinate values from its two P oint parameters: the specific Wi NDOW I MP subscript supports different window systems. , X WINDOW I MP Subcommination X Wi NDOW Window System: For Presentation Manager (PM), we define PM Wi NDOW I MP classes: These subclass window systems implement Wi NDOW I MP operation, for example, for X Window system achieves D Evice R ECT: PM implementation part like this: Chapter 4 Structure mode 1 0 5
Then how the window gets the correct Wi N D O W I m p subclass example? In this example we assume that the Window class has this responsibility, its G e t Wi N D O W i m p operation is responsible for getting the correct instance from an abstract factory (see Abstract Factory (3.1) mode), this abstract factory encapsulates details of all window systems. Wi N D O W S Y S TE:: I N S T A N c E () Function Returns an abstract factory that handles all objects associated with a particular window system. For simplicity, we create a single piece (S i N G L e t o n), allowing Wi N D O W class to directly access this plant. 11. It is known that the application above Wi N D O W is from E T [W G M 8 8]. In E T , Wi N D O W I m P is referred to as "Wi N D O W P O R T", which has some subclasses such as X Wi N D O W P O R T and S U N Wi N D O W P O R. Wi N D O W Object Request a abstract factory called "Wi N D O W S Y S TE E M" creates the corresponding I M P L E M E N T O R object. Wi N D O W S Y S TE E M provides an interface for creating some objects associated with a particular platform, such as fonts, cursors, bitmaps, and the like. E T Wi N D O W / Wi N D O W P O R T Design Extension B R I D G E mode because Wi N D O W P O R T retains a pointer to Wi N D O W. The I m P L e m e n t O R of Wi N D O W P O R t uses this pointer to notify the Wi N D O W object, and some events related to Wi N D O W P O R T: For example, the arrival of the event, the window adjustment is large. Coplien [COP92] and S T R O U S R u p [S T R 9 1] all mentioned H a N D L E class and some examples have been given. These examples centralize some memory management issues, such as shared string expressions, and objects that support size variable. We mainly care about how it supports independent expansion of an abstraction and its implementation. The L i b G [L E A 8 8 8] The class library defines some classes to achieve common data structures, such as S E T, L i Nk E D S E T, H A S Hs E T, L i N K E D L I S and H A S H TA B L E. S e t is an abstract class that defines a set of abstract interfaces, and L i n k E d L I S and H A S H TA B L E are specific implementations of the linked list and the H A S H table, respectively. L Inked S et and H ASH S is the implementation of S et as the implementation of S et as S et as a specific C ISH Table. This is a degraded bridge mode because there is no abstract I Mplementor class. 1 0 6 Design mode: can be used for object-oriented software
N e x t s appkit [add94] uses B R I D G E mode in image generation and display. An image can have a variety of different representations, and the best display mode of an image depends on the characteristics of the display device, especially its color number and resolution. If there is no help of A Pk I T, the application developers in each application must determine which implementation method should be used in different situations. To alleviate the burden of the developer, A P P K i t provides N x I m a g E / N x I m a g e R EP bridge. NTI Mage defines the interface of the image processing, and the implementation of the image interface is defined in the stand-alone NXI Mage R EP class hierarchy, which contains multiple subclasses, such as NXEPSIMAGEREP, NXB IT M AP i MAGE R EP, etc. N x i m a g e maintains a pointer, pointing to one or more N x i m a g e r e p objects. If there are multiple image implementations, N x i m a g e selects an image implementation that best suits the current display device. If N x i m a g e can convert one implementation into another implementation. This B R i D g E mode is very interesting to species: N x i m a g e can store multiple N x i m a g e R E P implementation at the same time. 12. Related Mode Abstract Factory (3.1) mode can be used to create and configure a specific B R I D GE mode. Adapter (4.1) mode is used to help unrelated classes, which usually use after the system design is completed. However, B R i D g E mode is used when the system starts, which makes the abstract interface and the implementation portion can be independently changed. 4.3 Composite - Object Structure Type 1. It is intended to combine the object into a tree structure to represent the hierarchy of "partial - overall". C O m P O S I makes the user consistency for the use of a single object and a combined object. 2. Motivation In a graphics application such as a drawing editor and a graphic capture system, users can create complex charts using simple components. The user can combine multiple simple components to form some larger components, which can also be combined into larger components. A simple implementation method defines some classes such as TE X T and L i N e to define some classes as the container classes (C O N n n n e r) of these primitives. However, this approach has a problem: using these classes must distinguish the object to the container object, and in most cases, the user thinks them is the same. Use these types to use to make the program more complicated. The C O m P O S I T E-mode describes how to use a recursive combination such that users do not have to distinguish these classes, as shown below. The key to the Composite mode is an abstract class that can represent both the chamber and can represent the container of the primitive. This class in the graphics system is G R A P H i C, which declares some operations related to a particular graphic object, such as D R A W. At the same time, it Chapter 4 Structured Model 1 0 7
Some operations shared by all combinations are also declared, such as some operations for accessing and managing its sub-parts. Sub-class L i n E, R E C T A N g L E and TE X T (see the previous class diagram) define some primitive objects that implement D R A W, which are used to draw straight lines, rectangles, and body, respectively. Since there is no sub-pattern, they do not perform operations related to subclavab. The P i c t U r C defines the aggregation of a Graphic object. The Picture's D R A W operation is achieved by calling D r a W for its sub-component, and P i c T U R is also implemented in this method to achieve some operations related to its sub-components. Since the P i c t UR e interface is consistent with the G R a P H i C interface, the P i c t U RE object can be recursively combined with other P i c T u r e objects. The figure below is a typical combination object structure consisting of a combined combination G R a P H i C object. 3. Applicability The following uses C O m P O S I TE mode: • You want to indicate part of the object - the overall hierarchy. • You want the user to ignore the unlike a single object, and the user will unify all objects in the combined structure. 4. Structure Typical C O M P O S I T E object structure is shown below. 1 0 8 Design mode: can be used for object-oriented software
5. Participants • Component (graphic) - Declare the interface for the object in the combination. - In appropriate, you can realize the default behavior of all classes. - Declare an interface for accessing and managing subcomponents of C O M P O N e N t. - (Optional) Defines an interface in the recursive structure to access a parent part and implement it in a suitable case. • Leaf (Rectangle, L i N E, TE X T, etc.) - indicating a leaf node object in a combination, and the leaf node has no child node. - Define the behavior of a primitive object in a combination. • Composite (Picture) - Defining the behavior of those parts of the sub-part. - Storage subfigure. - Realize the operation related to the sub-components in the C O m P O N e n t interface. • Client-manipulate the object of the combined part by the C O m P O N e n t interface. 6. Collaboration • Users interact with objects in the combined structure using the C O m P O N e n T interface. If the recipient is a leaf node, the request is directly processed. If the recipient is Composite, it usually sends the request to its sub-components, and may perform some auxiliary operations before and / or after forwarding the request. 7. Effects C O m P O S I TE Mode • Defined a class hierarchy of a class hierarchy including a basic object and a combined object can be combined into a more complex combination object, and this combined object can be combined, so constantly recursive. In the customer code, any combination object can be used in places where basic objects can be used. • Simplify customer code customers can consistently use combined structures and individual objects. Usually the user does not know (nor carefillation) processing is a leaf node or a combination component. This simplifies the customer code, because there is no need to write a function that is full of selection statements in those classes that define a combination. • Make more easier to add new types of components newly defined C O m P O S i t e or L E a F subclass work with existing structures and customer code, and customer programs do not need to change due to new C O m P O N e n T. • Make your design more generally easier to increase new components will also generate some problems, that is, it is difficult to limit the components in the combination. Sometimes you want a combination to have some specific components. When using C O m P O S I T, you cannot rely on the type system to apply these constraints, but must be checked at runtime. 8. Implementing the following issues in implementing C O m P O S i t E mode: 1) Explicit parent component references maintain the traversal and management of combined structures from the reference to the parent component. The parent component reference can simplify the upper movement of the structure and the deletion of the component, and the parent component reference also supports the Chain of Responsibility (5.2) mode. Parent part references are typically defined in the C O m P O n e n T class. L E A F and C O M P O S i TE E Class can inherit this reference and manage this reference. Chapter 4 Structure Model 1 0 9
For parent components, an invariant, that is, all combinations of sub-nodes are parental nodes in this combination, and the combination is the combination to be a child node. The easiest way to ensure this is that the parent part of the component is changed only when a component is added or deleted in a combination. If this method can be implemented in the ADD and R E M O V e operation of the C O M P O S i TE E-class, all subclasses can inherit this method and will automatically maintain this invariance. 2) The shared component sharing component is useful, such as it can reduce the demand for storage. But when a component has only one parent part, it is difficult to share the component. A viable solution is to store multiple parent components for the child, but this method will cause polynsity when a request is transmitted upward in the structure. F L Y W E I G H T (4. 6) The mode discusses how to modify the design to avoid being stored together with the parent part. If the sub-component can store some status (or all state) outside so that this method is feasible without sending a request to the parent component. 3) One of the purposes of maximizing C O M P O N e n T interface C O m P O S I TE E-mode is to make the user do not know the specific Leaf and C O M P O S i T e-class they are using. In order to achieve this, C O m P O S I t e defines as many common operations as possible for Leaf and C O M P O S I t e. C O m P O S i TE E-class usually provides default implementation for these operations, while LEAF and C O M P O S I T E subclasss can be redefined. However, this goal may sometimes conflict with the principles of class hierarchical design, this principle provides: A class can only define the meaningful operations that are meaningful to its subclasses. There are many operations supported by many C O m p o n e n t, and how does C O m P O N e n provide a default operation? Sometimes a point of creativity can make a manner that looks only for C O m P O S i t e, put it into the C O m P O N e n T class, is applicable to all C O m P O N e n t. For example, an interface to an access sub-node is a basic component of the C O m P O S i TE E class, but it is not necessary for the L E A F class. But if we see a L EAF as a Component without a child node, you can define a default action in a C OMPONENT class, which is used to access the child node. This default operation does not return any child node. . The Leaf class can use the default implementation, while the C O M P O S i TE is reinforce this operation to return their subclasses. The management of sub-components is more complicated, and we will discuss in the next item. 4) Declaring management sub-components Although the C OMPOSITE class implements the ADD and R EMOVE operations for managing sub-components, an important issue in C OMPOSITE mode is: Which class declarations in the C OMPOSITE class hierarchy . We should declare these operations in C O m P O N e N t, which makes these operations make sense to LEE A F, or should also be declared in C O M P O S I TEE and its subclass? This requires a trade-off between security and transparency. • The method of the root defined sub-node management interface in the class hierarchy has good transparency because you can consistently use all components, but this method is at the expense of security, because the customer may do some Significant things, such as increasing and deleting objects in LEAF.
• The method of defining the management sub-component in the C O m P O S i T e class has good security, because in the static type language like C , an attempt to increase or delete an object from Leaf at the time of compilation will be discovered. However, this has lost transparency because LEAF and C O M P O S I T E have different interfaces. In this mode, we compare transparency relative to security. If you choose security, sometimes you may lose type information and have to convert a component into a combination. Such type conversion must not be type safe. One way is to declare an operation Composite * getComposite () in the C O m P O N e n T class. C O m P O N e N t provides 1 1 0 Design mode: The basic software-oriented software is available for the default operation of the null pointer. C O m P O S i t e redefines this operation and returns itself through the T H I S pointer. GetComposite allows you to check if a component is a combination, you can safely perform the add and R E M O V e operation on the returned combination. You can use the D Y n a m i c _ C a S t structure in C to do a similar test of C O m P O S I t e. Of course, the problem here is that we do not match all components. We must detect different types before making the appropriate action. The only way to provide transparency is to define the default ADD and R E M O V e operation in C O M P O N e N t. This brings a new problem: C O m p o n e n t:: The implementation of a d d will inevitably have the possibility of failure. You can do not let C O m P O n e n:: a d d Do anything, but this is ignored a very important issue: trying to add something to the leaf node to introduce errors. At this time, A D D operation generates garbage. You can let A D D delete its parameters, but may not want this. If the component does not allow a sub-component, or the parameter of R E M O V E is not the child node of the component, it is generally preferred to use default mode (possibly generating an exception) to process A D D and R E M O V E. Another way is to change some changes to the meaning of "delete". If the component has a parent component reference, we redefine the component :: removent :: Remove, remove this component in its parent component. However, the corresponding A D D operation still has no reasonable explanation. 5) Component should implement a C OMPONENT list You may want to define the child node collection as an instance variable in the C OMPONENT class, and some operations of the sub-node to access and tube Chapter 4 are also declared in this C OMPONENT class. Model mode 1 1 1
. However, in the base class, the loop pointer is stored, which causes space waste due to the leaf node, because the leaf node does not have a child node. This method is only worthwhile to use when the number of subclasses in this structure is relatively small. 6) Submount Sort Many Design Specify the sub-component sequence of C O m P O S I T E. In the previous G R a P H i c s example, sorting may indicate the order of origination from the previous. If C O M P O S I TE e-sequence must reflect the program structure in the order of the syntax analysis tree, the C O m P O S I T E sub parts must reflect the program structure, and the combined statement is an example of some of the C O m P O S I t e. If you need to consider the order of child nodes, you must carefully design the access and management interface of the child node to manage the child node sequence. I TE E R A T O R Mode (5. 4) can be given some guidance in this regard. 7) Use cache storage improvements If you need to traverse or find the combination, the C O m P O S i TE can buffer information about its sub-node to traverse or find. C O M P O S I T E can buffer the actual result or is only some information for shortening traversal or query length. For example, the P iCTURE class can cache the boundary box of the sub-component in an example, during the drawing or selection, this bounder box makes it need to perform Drawing or choice. When a component changes, its parent components originally buffer stored information is also invalid. This method is most effective when the component knows its parent components. Therefore, if you use a cache storage, you need to define an interface to notify the combination components that they buffer is invalid. 8) Who should delete Component in a language without a garbage collection mechanism, when a C O m P O S i t e is destroyed, it is preferably preferably a sub-node from C O M P O S i TE. However, there is an except that the LEE A F object does not change, so it can be shared. 9) The storage assembly preferably uses which data structure C O M P O S I TEE can store their sub-nodes using a variety of data structures, including connection lists, trees, arrays, and H a s h tables. The selection of the data structure depends on the efficiency. In fact, it is not necessary to use the general data structure. Sometimes each sub-node, C O m P O S i t e has a variable corresponding to the CO M P O S I T, each subclass of C O m P O S, to implement its own management interface. See example in I N T E R P R E T E R (5. 3) mode. 9. Code example computer and stereo combined audio This is often assembled into a portion-overall hierarchy or a container hierarchy. For example, a chassis can include a drive device and a flat panel, and a bus contains a plurality of plugins, and the cabinet includes a chassis, a bus, and the like. This structure can naturally simulate using C O m P O S I T E-mode. E Q U I P M e n T Class is a interface that defines an interface in all devices in a portion-overall hierarchy. 1 1 2 Design mode: can be used for object-oriented software
Equipment declares that some operations return a device's properties, such as its energy consumption and prices. The subclass is implemented for the specified device, and E Q u pm e n t also declares that a C R E A TET E I TET ER A T O R operation is returned to a part of the part returns an I T E R A T O R (see Appendix C). The default implementation of this operation returns a N u L i t E R A T O R, which is superimposed in the empty set. Equipment's subclasses include LEE c class representing disk drives, integrated circuits, and switches: CompositeEquipment is a base class containing other devices, which is also subclasses of E Q U I P M e n t. C O m P O S i t e q u i pm e n T defines some operations for access and management subscons. Operation ADD and R E M O V e Insert and delete the device from the list of devices stored in the _ e q u i pm e n t. Operation C R e a t e i t e R A T O R Returns an album (one instance of L i S T I T E R A T O R) traversing this list. The default implementation of N e T P R I c e uses createiterator to accumulate the actual price of the child equipment. Now let's represent the computer's chassis as the subclass C H A S I S of C O M P O S I T E E E q U IP M E N T. CH A S S I S inherits those operations associated with subclasses from C O m P O S I t e q u I pm e n t. Chapter 4 Structure Model 1 1 3
It is easy to forget to delete it when you run the i t e r a t o r. I T E R A T O R Mode describes how to handle such issues. We can define other equipment containers such as C A b i n e t and b u s. In this way we got all the equipment required to assemble (very simple) personal computers. 10. It is known to have a Composite mode application example in all object-oriented systems. In the M Odel / Vi EW / C ontroller [KP 8 8] structure in S Malltalk, the original VI EW class is a Composite, almost every user interface toolbox or framework follows these steps, including ET (with VO BJECTS) [WGM 8 8]) and I NTER VI EWS (S Tyle [LCI 9 2], G Raphics [VL 8 8] and G Lyphs [CL 9 0]). It is very interesting that the original VI E w in Model / Vi E W / C O N T R O L1 has a set of sub-views; in other words, View is both the Component class, and the C O m P O S i t e-class. 4. The S M A l T a l k - 80 was modified with VI S U A L C O m p O N e n-type containing subclass VI E W and C O M P O S I t e vi e w. RTL SmallTalk Compiler Frame [J M L 9 2] A large number of C O m P O S i t E mode is used. RTLEXPRESSION is a C O m P O N e n T class corresponding to the syntax analysis tree. It has some subclasses, such as B i n a r y e x p r e s s I O n, and B I n a r y e x p r e S I O N includes sub-RT L e x P R e S I O N object. These classes define a combined structure for the syntax analysis tree. R E G I S TER TR A N S F E R is a Component class in the form of a program. CoMPONENT class. The L e A F subclass of R e g i s t e R TR a N s F E R defines some different static assignments, such as: • Basically assignment, perform operations on two registers and put the result into the third register. • With a source register but no target register, this shows that the register is used after the routine returns. • The assignment of the target register but the passive register, this shows that the target register is assigned before the routine begins. Another sub-class R e g i s e r TR a N S f E R s E t, is a C O m P O S I t-class, which represents the assignment of several registers at a time. Another example of this mode appears in the field of financial applications, in which a combination of assets aggregates multiple individual assets. In order to support complex asset aggregation, the asset portfolio can be achieved with a C O m P O S I t-class, which is consistent with the interface of a single asset [B E 9 3]. C O m m a n d (5. 2) Mode describes how to consist of some C O m M A N D objects with a Macrocommand Composite class and sort them. 11. Related Mode Usually Components - Parent Parts Connects for Responsibility Of Chain (5.1) mode.
D E C O R A T O R (4. 4) mode is often used with the C O m P O S I t-mode. When decorated and combined, they usually have a public parent class. Therefore, the decoration must support C O M P O N e n T1 1 4 design modes for A D D, R E M O V E and GetChild operation: the foundation interface for object-oriented software can be multiplexed. F L Y W E G H T (4. 6) Let you share components, but no longer reference their parents. I T E R T O R (5. 4) can be used to traverse C O M P O S I TEE. VI S i T O R (5. 11) The operation and behavior of the CO M P O S I T E and L E A c class should be originally distributed. 4.4 Decorator - Object Model Mode 1. It is intended to dynamically add some additional duties to an object. In terms of increased function, D e C O R A T O R is more flexible compared to generated subclasses. 2. Alsen wrapper WR a P P e R3. Motivation Sometimes we want to add some functions to an object rather than the entire class. For example, a graphical user interface toolbox allows you to add some features to any user interface component, such as a border, or some behavior, such as a window scrolling. The use of inheritance mechanisms is an effective way to add functions, from other classes inherited border characteristics can be used by multiple subclasses. But this method is not flexible, because the choice of the border is static, the user does not control the way and timing of the components. A more flexible way is to embed the component into another object, and add a border by this object. We call this embedded object for decoration. This decoration is consistent with the components it decorated, so it is transparent to the client that uses the component. It forwards the customer request to the component and may perform some additional actions before and after forwarding (for example, draw a border). Transparency allows you to recurrent a plurality of decorations, allowing any multi-function, as shown below. For example, assume that there is an object TE X T VI E W that can display the body in the window. The default TE X t vi e w does not have a scroll bar because we may sometimes do not need a scroll bar. When the scroll bar needs to be scrolling, we can add a scroll bar with S C R O L D e C O R A T O R. If we also want to add a rough black border around TE X T Vi E W, you can add it to B O R D E R D E C O R A T O R. Therefore, as long as these decorations and TE X T Vi E w are combined, the expected effect can be achieved. The following object map shows how to assemble a TE X T Vi E W object with B O R D E R D E C O R A T O R and S C R Otte Generation Generation A Text Display Window having a border and scroll bar. Chapter 4 Structure Model 1 1 5
S c R O L1 E C O R A T O R and BorderDecorator classes are subclasses of D e c O R A T O R class. D E C O R A T O R is an abstract class of a visual component for decorating other visual components, as shown below. VI S U A L C O M P O N e N is an abstract class describing the visual object, which defines the interfaces of drawing and event processing. Note How to simply send the plot request to its components, and how the subclasses of D E C O R A T O R extend this operation. Subclasses of D E C O R A T O R are free to add some operations to specific functions. For example, if other objects know that there is a S c R O L D e c O R A T O R object in the interface, these objects can be scrolled with the S c R O L TO operation of the S c R O L D e c O R A T O R object. One thing in this mode is important, which makes it can be decorated anywhere in VI S U A L C O M P O N e N t. Therefore, customers usually do not feel the difference between the decorated components and the unfilled components, and will not have any dependencies with the decoration. 4. Applicability The following uses D E C O R A T O R Mode • Add responsibility to a single object in a dynamic, transparent manner without affecting other objects. • Handle those responsibilities that can withdraw. • When the method of generating subclasses cannot be expanded. One case is that there may be a large number of independent extensions, to support each combination, which will generate a large number of subclasses, resulting in explosive growth. Another situation may be because class definitions are hidden, or class definitions cannot be used to generate a subclass. 5. Structure 1 1 6 Design mode: can be used for object-oriented software
6. Participants • Component (VI S U A L C O M P O N e N T) - Defines an object interface to dynamically add responsibilities to these objects. • C O N C R E TET (TE X T VI E W) - Defines an object to add some responsibilities to this object. • D E C O R A T O R-Retores a pointer to the C O m P O N e n T object and defines an interface that is consistent with the C O m P O N e n t interface. • C O N C R E T E D E C O R A T O R (B O R D E R D E C O R A T O R, ScrollDecorator) - Add responsibility to the component. 7. Collaboration • D e c O R A T O R forwards the request to its C O m P O N e n T object, and may perform some additional actions before and after the forwarding request. 8. Effects D ecorator models have at least two main advantages and two shortcomings: 1) More flexible than static inheritance is more flexible to add responsibilities to objects than static inheritance (multiple inheritance), D ecorator mode . You can use the addition and separation method to increase and delete duties with decoration at runtime. In contrast, the inheritance mechanism requires a new subclass for each added responsibilities (for example, B O R D E R S C R O L A B L ETE X T Vi E W, BORDEREDTE X T VI E W). This will produce many new classes and will increase the complexity of the system. In addition, a plurality of different D e C O R A T O R classes are provided for a specific C O m P O N e n T, which allows you to mix and match some responsibilities. Adding a feature can be easily repeated using D e c O R A TO R mode, for example, when adding a border on TE X T VI E W, it is only necessary to add two B O R d E R d E C O R A t O r. Two inherited B o R d E R is extremely easy to make mistakes. 2) Avoid too much feature DE C O R A T O R mode provides a "ready" method to add responsibilities. It does not attempt to support all predictable features in a complex customized class. Instead, you can define a simple class and gradually add functions to it with D e C O R A T O R. Complicated functions can be combined from simple components. This way, the application does not have to pay for unwanted features. It is also easier to independently define new types of D e C O R A T O R independently, independently, independently, independent, independently, independently defined (even unpredictable extensions). When expanding a complex class, it is likely to expose a detail that is not related to the added responsibilities. 3) Decorator and its C O m P O N e N D Different DE C O R A T O R is a transparent package. If we start from the viewpoint of object identity, a decorated component is different from this component, so it should not rely on object identity when using decoration. 4) There are many small objects to use D Ecorator mode to make system designs often produce many small objects that look similar, these objects are only different in their way, rather than their class or their attribute values. Different. Although those who understand those systems are easy to customize, it is difficult to learn these systems, and it is also difficult to troubleshoot.
9. Implementing the following: 1) The following: 1) Consistent Decorative object's interface must be consistent with the interface it decorated, so all C Oncrete D ecorator classes must have one The public parent class (so in C ). Chapter 4 Structure Model 1 1 7
2) omission abstract DE C O R A T O R Class When you only need to add a responsibility, there is no need to define an abstract D e C O R A T O R class. You often need to handle existing class hierarchies rather than design a new system. At this time, you can combine DE C O R A T O R to C O m P O N e n t forward requests to C O N C R E TED E C O R A T O R. 3) Maintaining the simplicity of the C O m P O N e n T class In order to ensure the consistency of the interface, the components and decorations must have a common C O m P O N e n t parent class. Therefore, it is important to maintain this simpleness; that is, it should focus on defining interfaces rather than storing data. The definition of data representation should be delayed into the subclass, otherwise the C O m P O N e n T class becomes too complicated and huge, so it is difficult to use a lot. The function assigned to C O m P O N e N t is also made, and the specific subclasses have some possibility that they do not need to increase. 4) Change the object housing and change the kernel we can view D E C O R A T O R as a housing of an object, which can change the behavior of this object. Another method is to change the kernel of the object. For example, S T R A T E G Y (5. 9) mode is a good mode for changing the kernel. When the C O m p o n e n T class is very large, the cost of using D e C O R A T O R is too high, and S T R a T E G Y mode is relatively better. In S T R A T E G Y mode, components forward its behavior to a stand-alone policy object, we can replace the S T R a T E G Y object to change or expand the functionality of the component. For example, we can delay the functionality of the component to a stand-alone B O R D e R object, which can support different boundary styles. This B O R D e R object is an S t R A T E G Y object, which encapsulates the boundary drawing strategy. We can use the number of strategies from one to any plurality, and the effect is the same as the nested nested to the decoration. In M AC A PP 3. 0 [A PP 8 9] and B Edrock [S YM 9 3 A], the drawing assembly (called "view") has a list of "Deco" objects, which are available To add some decorations, such as a border. If you add some decorations to a view, you can use these decorations to make some additional modifications. Since the VI E W class is too large, M a C A P P and B E D R O C K must use this method. Use a complete VI E W using only a border, the cost is too high. Since the D e C O R A T O R mode changes only from the outside, the components do not have any understanding of its decoration; that is, these decorations are transparent to the assembly, as shown below. In the S T R A T E G Y mode, the C O m P O N e n t itself knows which expansion may be presented, so it must be referenced and maintained, as shown below. The method based on S T R A T E G Y may need to modify C O m P O N e n t components to accommodate new expansion. On the other hand, a strategy can have its own specific interface, and the decorated interface must be consistent with the interface of the component. For example, a strategy of a drawing border requires only the interface of the generated border (D R A W B O R D E R, GetWi D T H, which means that the strategy can be small even if the C O m P O N e n t is very large. 1 1 8 Design mode: can be used for object-oriented software
Decorator-extended features Strategy-extended features M A C A P P and B E D R O C K, which is not only used for decorative views, but also for enhancing the event processing capability of the object. In both systems, each view maintains a list of "behavior" objects, which can modify and intercept events. This view gives each registered object a chance to handle events before the registered behavior object is not registered. You can use a special keyboard to support the decorative one view, for example, you can register an acts to intercept and process the keyboard event. 10. Code Example The following C code illustrates how to implement user interface decoration. We assume that there is already a C O m p O N e n T-type Vi S U A L C O m P O N e n t. We define a subclass D e C O R A T O R of VI S U A L C O M P O N e N, we will generate subclasses of D e c O R A T O R to obtain different decorations. DE C O R A T O R Decorates the VI S U A L C O M P O N E N t referenced by _ C O m P O N e N T instance variable, which is initialized in the constructor. For each operation defined in the VI Sual C OMPONENT interface, the D ecorator classes define a default implementation, this implementation will forward the request to _ Component: D ecorator subclass defines a special decorative function, for example B The Order D ecorator class adds a border to the components it contains. B O R D E R D E C O R A T O R is a subclass of D E C O R A T O R, which redefines D R A W to operate the border. At the same time, B O R D E R D E C O R A T O R also defines a private auxiliary operation D R A W B O R D E R that draws a border by it. These subclasses inherit all other operations of D E C O R A T O R Class. Chapter 4 Structured Model 1 1 9
Similarly, S C R O L D E C O R A T O R and D R O P S H A D O W D E C O R A T O R can be achieved to add rolling and shadow functions to the visible components. Now we combine these instances to provide different decorative effects. The following code shows how to create a boundary rolling TE X T Vi e w using D E C O R A T O R. First we have to place a visual component into the window object. We assume that the Wi NDOW class has provided a S et c ontents: Now we can create a text view and put the window to this text view: TE XT Vi EW is a VI Sual C OMPONENT, which can be placed in the window : But we want a border and can scroll to TE XT Vi EW, so we decorate it before putting it in the window: Since Wi NDOW accesss its content through the VI Sual C Omponent interface, it does not Know that there is this decoration. If you need to interact directly with your text, for example, you want to call some operations, and these operations are not part of the VI S U A L C O M P O N e N T interface, and you can track a text view. Customers depend on the component identifier should also directly reference it. 11. It is known to use many object-oriented user interface toolboxs to add graphic decorations for window components, such as I NTER VI EWS [LVC89, LCI 92], ET [WGM88] and O Bject Wo RKS / S MALLTALK class library [ P Ar 9 0]. Some special applications of DE C O R A T O R Mode include I N T E R Vi E W S DE B U G G G G G L Y and P A S I V I T Y WR A P P E R of ParcPlace SmallTalk. DE B U g g i n g g l y p h Prints the debug information before and after forwarding the layout request. These tracking information can be used to analyze and debug a layout behavior of an object in a complex combination. P A S S i V i T Y WR A P P E r can allow and prohibit the interaction of users from components. However, D e c O R A T O R is not limited to the graphical user interface, the following example (based on E T S t R E a M I N G [W G M 8 8]) illustrates this. S Treams is the basic abstract structure of most I / O devices, which provides an object to an operation interface that converts objects into bytes or character streams, allowing us to convert an object into a string in a file or memory, which can be later Reuse. A simple and straightforward method is to define an abstract S T R E a M class, which has two subclass M E M O R Y S T R E A M and F I L E S T R E A M. But suppose we also hope to do some things: 1 2 0 Design mode: can be used to object-oriented software
• Compress data streams with different compression algorithms (stroke codes, Lempel-Ziv, etc.). • Simplify stream data to 7-bit A S c i i code characters so that it can be transmitted on the A S C I I channel. Di C O R A T O R Mode provides these functions to the S T r e a m. The following class diagram gives a method of solving the problem. The S TR E a M abstraction focuses an internal buffer and provides some operations (PUTINT, PUTSTRING) is used to store data into the stream. Once this buffer is full, S t R e a m calls the abstract operation H a n d L E B U FF E R F U L1 for actual data transmission. This operation is defined in F i L e s T R e a m to transfer data in the buffer to the file. The key class here is S Tream D ecorator, which maintains a pointer to the component stream and forwards the request to it, the S Tream D ecorator subclass redefine H ANDLE B U FF Er F ULL operation and call S Tream D ecorator Handle B U ff er f ULL Operations Execute some additional actions. For example, C O m P R e s S I n g s T r e A M subclass is used to compress data, and A S C I 7 S T R E A m converts data to 7-bit A S c I I code. Now we create a F Ile S Tream class, which first compresses the data, then converts the compressed binary data into 7-bit ASCII code, we use C OMPRESSING S TREAM and ASCII 7 S Tream Decorative F Ile S Tream: 12. Related mode A DAPTER (4. 1) mode: D ecorator mode is different from the A Dapter mode because it is decorated only to change the responsibility of the object without changing its interface; the adapter will give an object a new interface. C O m P O S I T E (4. 3) mode: Decoration can be deemed as a degradation, only one component combination. However, decoration adds some additional responsibilities to objects - it is not to gather in objects. S T R A T E G Y (5. 9) mode: Use a decoration you can change the appearance of the object; and the S T R A T E G Y mode allows you to change the kernel of the object. This is two ways to change the object. 4.5 FACADE - Object Structure Type 1. It is intended to provide a consistent interface in a set of interfaces in the subsystem, and F A c a d E mode defines a high-level interface. This link 4 Structural mode 1 2 1
The mouth makes this subsystem easier to use. 2. Motivation will divide a system into several subsystems that facilitate reducing the complexity of the system. A common design goal is to minimize communication and interdependence between subsystems. One of the ways to achieve this is to introduce an appearance (F A C A D) object that provides a single and simple interface for a subsystem than a general facility in a subsystem. For example, there is a programming environment that allows the application to access its compilation subsystem. This compilation subsystem contains several classes, such as S C A N N E R, P RO E R, P RO G R A M N O D E, B Y T E C O D E S T R E A M and P R O G R A M N O D E B U I L D E R for implementing this compiler. Some special applications need to access these classes directly, but most compilers do not care about grammar analysis and code generation. They just want to compile some code. For these users, those who have powerful but hierarchical interfaces can only complicate their tasks in compiling subsystems. In order to provide a high-level interface and mask these classes to the customer, the compileration subsystem also includes a C O m P L I e R class. This class defines a unified interface of a compiler feature. C O m P i l E R class is an appearance that provides users with a single and simple compiler interface. It does not need to fully hide those classes that implement compilation, you can combine them together. The appearance of the compiler can be convenient for most programmers, while those who know how to use the underlying function, it does not hide these functions, as shown in the following figure. 1 2 2 Design mode: Accessible to object-oriented software-oriented basic customer class sub-system class class 3. Applicability In the following case, use F ACADE mode • When you want to provide a simple interface for a complex subsystem Time. Subsystems tend to become more complicated because of continuous evolution. Most mode uses more smaller classes. This makes the subsystem more reusability, and it is more easier to customize the subsystem, but this also brings some difficulties to those users who do not need to customize subsystems. F A C A D E provides a simple default view that is sufficient to most users, while those who need more customizable can cross the F A C A D e-layer. • There is a lot of dependence between the client program and the abstract class's implementation. Introducing F A C A D E separates this subsystem to customers, and other subsystems, can increase the independence and portability of the subsystem. • When you need to build a hierarchy subsystem, use the F A C A D E mode to define the entry point of each layer in the subsystem. If the subsystem is interdependent, you can make them communications only by F A C A D e, thereby simplifying the dependencies between them. 4. Structure 5. Participants • F A C A D E (C O m P i L E R) - know which subsystem classes are responsible for processing requests. - A request from the customer to the appropriate subsystem object. • Subsystem Classes (S C A N N E R, P A R, P R O G R A M N O D E, etc.) - the function of realizing subsystems. - Process the task assigned by the F A C A D e object. - No relevant information of F A c a d e, is not pointing to the pointer to F A C A D E. 6. Collaboration • The client program communicates with the subsystem via send request to the subsystem communication, and F A C A D E forwards these messages to the appropriate subsystem object. Although it is the actual work in the subsystem, the F A C A D E-mode itself must convert its interface into a subsystem interface. • Use F A C A DEE client does not need to directly access subsystem objects. 7. Effects F A C A D E - Some Advantages: 1) It is for the customer to block the subsystem components, thus reducing the number of objects processed and makes the subsystem more convenient. Chapter 4 Structure Model 1 2 3
Subsystem class 2) It realizes the loose coupling relationship between subsystems and customers, while the functional components inside the subsystem are often tight. Loose coupling relationship makes the components of the subsystem do not affect its customers. F A C A D E mode helps to establish a hierarchical system, which also helps the dependency between the objects. F A c a d E mode eliminates complex cyclic dependencies. This is especially important when the client program and subsystem are achieved separately. Reduce compilation dependence in large software systems is critical. When the subsystem class changes, you want to minimize the compilation operation to save time. Use F A c a d e to reduce compilation dependencies, restrict the re-translation of smaller changes in important systems. F A C A DE mode also helps to simplify the transplantation process between the system in different platforms, because compiling a subsystem generally does not need to compile all other subsystems. 3) If the application needs, it does not limit their use subsystem classes. So you can choose between system ease and versatility. 8. Realize the following points: 1) Note the following: 1) Reduce the coupling degree between the client-subsystem with abstract classes to implement f acade and its specific subclass corresponds to different subsystems, which can be further reduced The coupling of the client and subsystem. In this way, the customer can communicate with subsystems by abstract F A C A D e-class interface. This abstract coupling relationship makes the customer do not know which implementation it is using. In addition to the method of generating subclasses, another method is to configure F A c a d e object with different subsystem objects. To customize F A C A D E, it is only necessary to replace its subsystem objects (one or more). 2) A subsystem of public subsystems and private subsystems is similar to a class. They all have interfaces and they all encapsulate something - class packaged state and operation, and subsystem package some classes. Considering a class of public and private interfaces are beneficial, we can also consider the public and private interfaces of the subsystem. The common interface of the subsystem contains all the classes that the client can access; the private interface is only used to expand the subsystem. Of course, F A C A D e class is part of a common interface, but it is not the only part, and other parts of the subsystem are usually public. For example, the P a R S e-class and S c a n n e R in the compiling subsystem are part of the common interface. Private chemical class is really useful, but there are very few object-oriented programming languages. C and S M a L L t a l k language provides a full-bureau space for classes in the traditional sense. However, the recent C Standardization Committee adds some namespace [S T R 9 4] in the C language, which makes you only expose the public subsystem class. 9. Code example allows us to carefully observe how to use F A C A D e in a compiler system. The compilation subsystem defines a B Y T E C O D e S T R E A M class that implements a B Y T E C O D e object stream (S T R E A M). B Y T E C O D E object packages a range code, which can be used to specify the machine instruction. A TO K E N class also defines a TO K E N class, which encapsulates the identifier in the programming language. S c a n n e R Class receives a character stream and generates an identifier stream, generating an identifier (T O K E N) at a time. Use P R O g R A M N o D e b U I L D E R, and the P A R S E R is constructed by the identifier generated by S c a n n e r to construct a syntax analysis tree. 1 2 4 Design mode: can be used for object-oriented software
P A R S E R Tonance P R O G R A M N O D E B U I L D E R Steply Establish Syntax Analysis Tree, these clauses follow B U I L D E R (3. 2) mode to interact. The syntax analysis tree is constituted by the example of the P R O G R A M N o D E subclass (e.g., S T a T E M E NOD E E E E and E X P R E S I O N N). The P R O G R A M N O D E Hierarchy is an application example of the C O m P O S i TE mode. P R O g R A M N o D e defines an interface for operating the program node and its child node (if any). TR A V E R SE operation is parameter with a C O D E g e n e R a t O R as a parameter, and the P R O G R A M N o D subcarpse uses this object to generate machine code, the machine code format is B Y T E C O D e object in B Y T E C O D e S T R E A m. The C O D E g e n e R A T O R class is an interview with Chapter 4 Structure Model 1 2 5 Present (see VI S I T O R (5. 11) mode). For example, C O d E g e n E R a T O R is two sub-class S t a c k M a c H i n E C O D E g e n E R A T O R and R I S C C O D E G E N E R A T O R, which is different from different hardware architectures to generate machine code. Each class of P R O g R a M N o D E is a TR a V e R s E for the P R O G R A M N O D e sub object to the P R O G R A M N o D E. Each subclass sequentially does the same action on its child nodes, which has been recursive. For example, e x p r e s s I o N o D is defined to define TR a V e r s e: The class we discussed above constitutes a compilation subsystem. Now we introduce C O m P i L E R class, and C O M P L I e R class is a F A C A D E, which integrates all parts. C O m P i l e r provides a simple interface to compile source code for a particular machine and generate executable code. The above implementation is fixed in the code, and the programmer does not need to specify the structure of the target. This is reasonable if there is only one target machine. If there are multiple target machines, we may want to change the C OMPILER constructor to accept C Ode g ability as a parameter so that the programmer can refer to the 1 2 6 design mode when instantification C OMPILER: can be used to object-oriented software basis
A built-in generator. Facade of the compiler can also parameterize other participants such as S Canner and P Rogram N Ode B Uilder to increase the flexibility of the system, but this is not the main task of the F ACADE mode. Its main task is for general conditions. Simplify the interface. 10. The compiler example known in the code example section is inspired by O B J E C T WO R K S / S M A L T A L K Compilation System [P A R 9 0]. In e t application framework [W G M 8 8], the application can have a built-in browsing tool for monitoring its objects at runtime. These browsing tools are implemented in a separate subsystem that includes a F A c a d e class called P R O G R a m -M I N g E N V I R O N m E N t. This F A C A D e defines some operations (such as I N S P E C T O B J E C T and I N S P E C T C L A) for accessing these browsers. E T applications can ignore these built-in browser function, then P r o g r a m m i n g E n v i r o n m e n t implemented dummy operation on these requests; that is, they do nothing. Only E T P R O G R A M m M m M m m m m m m m m m m m m e n T subcategories use some of the operations that display the corresponding browser to implement these requests. Therefore, the application does not know if there is a built-in browser exists, and there is only an abstract coupling relationship between the application and the browsing subsystem. CHO I C e s operating system [C i r m 9 3] Use the F A C A D E mode to combine multiple frames together. The key abstraction in C H o I C e s is a process (P R O c e s s), stores (S t O R a g e) and address space. Each abstraction has a corresponding subsystem, implemented with a frame, supports the transplant between the C H O I C E S system in different hardware platforms. The two subsystems have a "represent" (which is F a c a d e), which are stored (F I l E S Y S T E M I N T E R F A C E) and address space (D O m a i n). For example, the virtual storage framework will D O M A I n as its F A C A D e. A D O m A I n represents an address space. It provides a mapping between the doubt address to a memory object, a file system, or an offset of the Backing Store. D O m A I N supports adding memory objects to a specific address, delete memory objects, and processing page errors. As shown in the figure above, there are some components inside the virtual storage subsystem: • MemoryObject represents data storage. • M E M O R Y O B J E C T C A C HE The m E M O R Y O B J E C T data is cacked in a physical memory. ME E M O R Y O B J E C T C A C HE is actually a S T R a T E G Y (5. 9) mode, which is positioned by it. • Addresstr A N s L A T I O N encapsulates address translation hardware. Chapter 4 Structure Model 1 2 7
Virtual Memory Box When a non-pages interrupt occurs, call R e P A I R f A U L T operation, D O m A I N finds a memory object at an address that causes a widaking interrupt and the RE P A I R f A U L T operation agent gives a cache associated with this memory object. The components of D O M A I N can be changed to customize D O M A I n. 11. Related Mode Abstract Factory (3.1) mode can be used with F A C A D E mode to provide an interface, which can be used to create subsystem objects in a single subsystem. Abstract Factory can also hide those class-related classes instead of F A C A D E-mode. The MEDIATOR (5.5) mode is similar to the F A c a d e-mode, it abstracts some of the features of existing classes. However, the purpose of M e D i a T O R is to abstract any communication between colleagues, usually in the function of any single object. Mi D i a t o r knows the intermediaries and communicates with it instead of communicating with other similar objects directly. Relatively, the F A C A D E mode is only abstracted on the interface of the subsystem object, making them easier to use; it does not define new features, and the subsystem does not know the presence of F A C A D e. Generally, only one F A C A D e object is required, so F A C A D e object is usually a Singleton (3.5) mode. 4.6 FlyWeight (Enjoyment Yuan) - Object Structure Type 1. It is intended to use shared technology to effectively support a large number of fine-grained objects. 2. Motivation Some applications have benefited from using object technology throughout its design, but simplified achievements greatly. For example, the implementation of most document editors has text-formatting and editing capabilities, which are modular to some extent. Object-oriented document editor typically uses objects to represent embedded components, such as tables, and graphics. Although the object is used to indicate that each character in the document will greatly improve the flexibility of the application, these editors are usually not doing so. Characters and embedded components can be handled and formatted to process, so that the application can be expanded without affecting other functions, supporting new character sets. The object structure of the application can simulate the physical structure of the document. The figure below shows how a document editor uses an object to represent characters. But the disadvantage of this design is that the cost is too large. Even a medium-sized document may also require hundreds of character objects, which takes a lot of memory and produces an unacceptable operation overhead. So it is usually not used for each character: the foundation for object-oriented software
The character object line object column object is indicated by an object. F L Y W E G H T Mode describes how to share objects such that they can use them finely without high cost. f L Y W E G H T is a shared object, which can be used in multiple scenes (C O N TExEx), and Fl Y W E I G H T can be used as a separate object in each scene - this point is not different from the instance of the non-shared object. f L Y W E G H t cannot make any assumptions to the scene it run, the key concept here is the difference between internal state and external state. The internal state is stored in F L Y W e i g h t, which contains information independently of the F L Y W E I G H T scene, which makes F L Y W E I G H T can be shared. The external state depends on the scene of F L Y W E G H T, and varies depending on the scene, therefore cannot be shared. The user object is responsible for passing the external state to F L Y W E I g H t when necessary. FL Y W E I G H T Mode is typically modeled for concepts or entities that are typically represented by the number of significant quantities. For example, a document editor can create a F L Y W E I G H t for each letter in the alphabet. Each F L Y W e i g h t stores a character code, but it can determine the formatting algorithm and the formatted command that is used when character appears in the document. Character code is internal state, while other information is an external state. Logically, a given character in the document has an object with an object, as shown in the following figure. However, each character is physically shared a F L Y, which occurs different from the document structure. Each appearance of a particular character object points to the same instance, this instance is located in the shared pool of the F L Y W E I G H T object. The class structure of these objects is shown below. G L Y PH is an abstract class of a graphic object, some of which may be F L Y W E I g H t. Those operations based on external states are passed to them as parameters. For example, D r a w and i n t e R s e c T s must know the scene where G L Y P H is located before execution, as shown in the next page. Indicates that the F l y w e i g ht of the letter "a" only stores the corresponding character code; it does not need to store the position or font of the character. The user provides information related to the scene, according to this information f L Y, Paint itself. For example, row glyph knows where its children should draw themselves to ensure they are aligned laterally. Therefore, ROW GLYPH can pass to each child in a plot request. Chapter 4 Structure Model 1 2 9
Since the number of different character objects is much smaller than the number of characters in the document, the total number of objects is far less than the number of objects used by the initial execution program. For one of the same fonts and color documents for all characters, no matter how long this document needs to assign 1 0 0 (approximately the number of A S c I i character set). Since most documents are not more than 1 0, the number in practical applications will not increase significantly. Therefore, it is practical to object abstraction for individual characters. 3. Applicability F L Y W E I G H T Mode The effectiveness depends largely on how to use it and where it is used. When all of the following is true: • An application uses a lot of objects. • Due to a large number of objects, large storage overhead is caused. • Most of the status of objects can be variable. • If you delete an external state of an object, you can replace a lot of group objects with relatively few shared objects. • The application does not depend on object identity. Since the F L Y W E I G H T object can be shared, the identification test will return true value for the conceptual obvious object. 4. Structure 1 3 0 Design mode: can be used for object-oriented software
The following object map illustrates how to share F L Y W E I G H t. 5. Participants • F L Y W E I G H T (G L Y) - describes an interface that can be accepted and acting on the external state by this interface F L Y. • C O N C R e t E f L Y W E I G H T (C H A R A C TE R) - Implements the F L Y ', and increasing storage space for internal state (if any). C O N C R e t e f L Y W E I G H T object must be shared. The status it stores must be internal; ie, it must be independent of the scene of the C O N C R e t e f L y W e i g h T object. • U N S H A R E D C O N C R E T E F L Y W E I G H T (R O W, C O L u m n) - Not all F L Y W E-I G H T subclasses need to be shared. F L Y W E I G H t interface makes sharing possible, but it does not force sharing. At certain levels of the F L Y W E I G H T object structure, U N S H A R E D C O N C R E TET object typically uses C O N C R e t e f L Y W E I G H T object as a child node (R O W and C O L u M n are like this). • f L Y W E G H T f A c t o R Y- Create and manage F L y w e i g h t objects. - Ensure that F L Y W E I G H T is reasonably shared. When the user requests a F L Y, F L Y, the F L Y, the object provides an created instance or creates one (if there is no existence). • Client - Maintain a reference to F L Y W E I G H T. - Calculate or store an external state of (multiple) F l y w e i g h t. 6. Collaboration • The state required for F L Y W E G H t is executed inside or outside. The internal state is stored in the C O N C R E TET object; and the external object is stored or calculated by the C L I e n T object. When the user calls the operation of the F L Y W E G H T object, the state is passed to it. • The user should not instantiate the C O N C R e T E F L Y W E I G H T, but can only obtain C O N C R e TEF L Y W E I G H T object from F L Y, which can be obtained from F L Y, which can be shared appropriately. 7. Effects When using F L Y, when transmitting, lookup, and / or calculate external states generate runtime, especially when F L Y W E I G H T is originally stored as an internal state. However, the saving of space offsets these overhead. The more F l y w e i g h t is shared, the greater the space saving. Storage savings determine the following factors: Chapter 4 Structured mode 1 3 1
• Because of sharing, the number of instances decreases • The average number of objects within the object • The external state is calculated or stored, the more F l y w e i g ht, the more storage saves. The savings increases with the increase of sharing. When the object uses a large number of internal and external states, and the external state is calculated and not stored, the energy conservation will reach the maximum. Therefore, two methods can be used to save storage: use the sharing to reduce the internal state consumption, with the calculation time to exchange the storage of external states. F L Y W E I G H T Mode is often combined with the C O m P O S I t e (4. 3) mode to represent a layer of hierarchical structure, which is a shared leaf node. The result of sharing is that the leaf node of F L Y W E G H t cannot store pointers that point to the parent node. The parent node's pointer will pass to F L Y W E G H T as part of its external state. This will have a big impact on the way to communicate between the objects in this hierarchy. 8. Implementing the following points: 1) Note the following: 1) Deleting an external status This mode is largely dependent on whether the external state is easily identified and it is removed from the shared object. If the number of external states and the number of shared pre-shared objects, the deletion of external state does not reduce storage consumption. The ideal condition is that the external state can be calculated from a separate object structure, and the storage requirements of the structure are very small. For example, in our document editor, we can store typographic layout information in a separate structure, rather than storing font and type information of each character object, and the layout map holds a run trajectory with the same typesetting information. When a character draws himself, it is used as the side effect of the drawing traversal. Because the font and type number of fonts used in the usual document are limited, the information is stored as external information, which is much more efficient than internal storage. 2) Managing Sharing Objects Because the object is shared, the user cannot instantiate it directly, so F L Y W E G H T -F A C T O R Y can help users find a particular F L Y W E I G H T object. F L Y W E G H T f A c t o R Y object often uses associated storage to help users find the F L Y W E G H T object for interest. For example, an F l y w e i g h t factory in this document editor has a F L Y W E I G H T Table with a character code as an index. The management program returns the corresponding F L y W e i g h t according to the resulting code. If there is no existence, create a F L y w e i g h t. Sharing also means some form of reference counting and garbage recycling, so when a F L Y W E G H T is no longer used, its storage space can be recovered. However, when F L Y W E I g H t is fixed and small (for example, the two operations are not necessary. In this case, F l y w e i g h t can be saved permanently. 9. Code example returns an example of our document editor, we can define a G L Y base class for the graphic object of F L Y W E G H T. Logically, G L Y PH is some C-O M P O S I T E-class (see C O M P O S I T E (4. 3)), it has graphical properties and can draw themselves. Here, we focus on the font properties, but this method also applies to other graphical properties of GL Y P H. 1 3 2 Design mode: can be used for object-oriented software
CHARACTER Subclass Store a character code: In order to avoid allocating storage spaces to each G L Y, font attributes, we can store this attribute in the G L y p h c O n t e x T object. G L Y P H C O N TET is an external state repository that maintains a simple mapping between GL Y P h and fonts (and some other possible graphics properties). For any operation, if it needs to know that G L Y's G L Y font is given in a given scene, there will be a G L Y's PH c O N TEEx instance to pass to it as a parameter. The operation can then query G L Y P H C O N TET EX T for font information in the scene. This scenario depends on the position of G L Y P H in the G L Y P h structure. Therefore, when G L y p h, the iterations and management operations of G L Y P H subclasses must be updated with G L y p h c o N t e x t. During the traversal, G L y p h c o n t e x t must be its current location in the GL Y P h structure. As the traversal is carried out, G L Y p h c o N t e x t: n e x t increases the value of _ I n d e x. The subclass of G L Y P h (eg, R O w and C O L u m n) to the N e x T operation must make it call G L y p h c o N t e x T in every point traversed:: n e x t. G L Y P H C O N TET:: g E T F O C U S Reactively uses the keyword of the B T R e E structure, and the B T R e-structure stores the mapping of G L y p h to the font. Each node in the tree is marked with the length of the string, and it gives this string font information. The leaf node in the tree points to a font, while the internal string is divided into a lot of sub-strings, each corresponding to a sub-node. The lower page is shown in a combination of a g l y p h: the B TR E E E E E E E E E E E E E E E E E E E E of the Font Information may be as follows: The internal node defines the range of the GL Y P h index. When the font changes or adds or deletes GL Y P h in the GL Y P h structure, B T R e E will be updated accordingly. For example, suppose we traverse to index 1 0 2, the following code sets the word "except" each character Chapter 4 Structure mode 1 3 3 of the font of the body around it (ie, with TIME 12 font, 12) -Point Times Roman's example): The new B Tree structure is shown below (black body display change): 1 3 4 Design mode: can be used for object-oriented software
Suppose we have to add a word D O N'T with 12-Point Times Italic font before the word "expect", including a space that keeps followed. It is assumed that the GC is still in the index position 1 0 2, the following code notification GC This event: B Tree structure becomes as shown below: When you query the current GL YPH font, it will search B Tree, at the same time Add an index until the current index font is found. Since the font variation frequency is relatively low, this tree is smaller than the GL Y P h structure. This will make the storage cost, and will not increase the query time. F L Y W E G H T f A c t o R Y is the last object we need, which is responsible for creating G L Y, and ensures reasonable sharing of them. G L Y P H f A C T O R Y class will instantiate C H A R A C T E R and other types of G L y p h. We only share CH A R A C T E R object; the combined G L y P h should be much less, and their important states (such as their child nodes) must be internal. _ c h a r a c t e R array contains some pointers, pointing to Character Glyphs indexed by alphabet code. This array is initialized to zero in the constructor. C R e a t e c h A r a c t E r looks for a character in the alphabetic array, and if it exists, return the corresponding G L Y P h. If there is no existence, C R e a t e c H A R A C T E r creates a G L y p h, put it in an array, and returns it: Chapter 4 Structural mode 1 3 5
The query time in this mechanism is proportional to the frequency of change in the font. When each character is font, the performance is the worst, but usually this is very small. Other operations only need to instantiate a new object every time, because the non-character G L y p h cannot be shared: We can ignore these operations, let the user directly instantiate the G L y p h. However, if we want these symbols to be shared later, you must change the customer code for creating their. 10. The concept of applying F L Y W e i g H t is first prior to I N T E R View 3.0 [CL90] and is used as a design technology. Its developer built a powerful document editor D o C, as a demonstration of F L Y W E G H T concept [C L 9 2]. D O c uses a symbol object to represent each of the characters in the document. The editor creates a g l y p h instance for the characters of each particular type (defined its graphic properties); so the internal status of a character includes character code and type information (index of type tables). This means that only the location is an external state, which makes D o C run fast. The document is represented by class D O C u m e n t, and it is also a F L Y W E I G H T f A C T O R Y. Tests for D O C indicate that sharing F L Y W E I G H t character is efficient. Typically, a document containing 1 8 0 0 0 0 characters only requires approximately 4 8 0 characters objects. ET [WGM88] uses F L Y W E I G H t to support visual style independence. Visual Standards affect the layout of each part of the user interface (eg, scroll bar, buttons, menu - collectively referred to as "Window Components") and their modified components (such as shadow, bevel). W i D g e t gives all layouts and drawing behaviors to a separate L A Y O U T object. Changing the L a y o U t will change the visual style, even if it is running at runtime. Each W i D g e T class has an L A Y O U T class corresponding (such as S C O L1 R L a Y O U T, M E N U B A R L A Y O U T, etc.). Using this method, an obvious problem is that the use of a separate L A y o U t will make the user interface object to be increased, because each user interface object will have an additional L a y o U t object. In order to avoid this overhead, the L-Y O U T object can be implemented with F L Y E E G H T. The effect of f L Y w e i g H t is very good because they work primarily to behavior definitions, and it is easy to pass some smaller external states to them, they need to use these status to arrange an object location or draw it. Object L a y o U t is created and managed by the L O O K object. The L O O K class is an ABSTRACT FACTORY (3. 1), which retrieves a specific L A Y O U T object with the operation of g e t b U t t t t o nl a y o u t and g e t m e n u b a rl a y o u t. For each visual style standard, there is a corresponding L O O K subclass (such as M O T I f L O K, O P E N L O O K) to provide the respective L A Y O U T object. By the way, the L A Y O U T object is actually S T R A T E G Y (see S T R A T E G Y (5. 9) mode). They are an example of the S T R A T E G Y object implemented by F L Y W E G H T. 11. Related Mode 1 3 6 Design mode: can be used for object-oriented software
In the previous code example section, the type information is external, so only character code is an internal state. Another way to achieve a visual style can be found in Abstract Factory (3.1) mode. F L Y W E I G H T Mode is typically combined with the C O m P O S I t e (4. 3) mode, a logically hierarchy is realized with a shared impeller. Typically, the S t a t e (5. 8) and S T R A T E G Y (5. 9) object are best to be implemented with F L Y W E I G H T. 4.7 Proxy (Agent) - Object Structure Type 1. It is intended to provide a proxy for other objects to control access to this object. 2. An alias surrogate3. One reason for accessing control over an object is to create and initialize it only when we do need this object. We consider a document editor that can embed graphic objects in the document. Some graphics objects (such as large grating images) have a great cost. But open documents must be very fast, so we should avoid all overhead of all overhead. Because not all of these objects are visible at the same time, it is not necessary to create these objects at the same time. This restriction condition means that for each overhead, it should be created as needed, and this will be generated as needed. But what do we use in the document replace this image? How can we hide the fact that the image is created as needed, so that the editor is complicated? For example, this optimization should not affect the code of drawing and formatting. The solution to the problem is to use another object, ie the image P R O X Y, replaces the real image. P R O X Y can replace an image object and instantiate the image object when needed. The image P R O X Y creates a real image when the DR A W operation of the document editor activates the image agent to display this image. P R O X Y directly forwards the subsequent request to this image object. Therefore, after creating this image, it must have a reference to this image. We assume that images are stored in a separate file. This way we can use the file name as a reference to the actual object. P R O X Y also stores the size of the image (e x T E N t), that is, its length and width. With image size, P R O x Y does not need to actually instantiate this image, you can respond to the formatting program to request an image size. The following class diagrams will be explained in more detail. The document editor accesss an embedded image through an interface defined by an abstract G R a P H i C class. I m a g e p r o x y is the class of images that need to be created, I m a g e p r o x y saves the file name as a pointer to the image file on the disk. The file name is passed to the constructor of I m a g e p r o x y as a parameter. I m a g e p r o x y also stores the border of this image and guidelines for true I m a g e instances until the agent instantizes the true image, this guidelines are valid. D R A W must ensure that it has been instantiated before forwarding the request to this image. G e t e x t e n T operation only passes the request to it after the image is instantiated, otherwise I m a g e p r o x y returns to it Chapter 4 Structure mode 1 3 7
The image size of the hard disk is stored in memory. 4. Applicability Use the P R O X Y mode when you need to use a relatively universal and complex object pointer to replace a simple pointer. Here are some common situations where P RO X Y mode can be used: 1) Remote Proxy provides a local representative for an object in different address space. Nextstep [add94] implements this with the N x P R O X Y class. Coplien [COP92] said this agent is "Ambassador" (A M B A S S A D O R). 2) Virtual Proxy) Create a large number of overheads that are overhead as needed. The I m a g e p r o x y described in the motivation section is an example of a proxy. 3) Protection Proxy controls access to the original object. Protecting agent is used for objects that should have different access rights. For example, K E M E L P R O X I e s provides access protection for operating system objects in C HO I C e s operating system [C i r m 9 3]. 4) Smart Reference replaces a simple pointer that performs some additional operations when accessing objects. Its typical use includes: • That is a reference to the actual object, so when the object is not referenced, it can be automatically released (also known as S M A R Tp O I N T E R S [E D E 9 2]). • When a persistent object is first referenced, it is loaded into memory. • Check if it has been locked before accessing an actual object to make sure other objects cannot change it. 5. Structure 1 3 8 Design mode: can be used for object-oriented software
This is an object map for running a possible proxy structure. 6. Participants • P R O X Y (I M A G E P R O X Y) - Save a reference to enable the agent to access the entity. If R E a L S UB J E C T and S UB J E C T are the same, P R O X Y will reference S UB J E C T. - Provide an interface as the interface of S UB J E C T, which can be used to replace the entity. - Control access to the entity and may be responsible for creating and deleting it. - Other features Depending on the type of proxy: • Remote Pro X Y is responsible for encoding the request and its parameters and transmits encoded requests to entities in different address spaces. • VI RTUAL Pro X Y can cache additional information of the entity to delay access to it. For example, the I m a g e P R O x Y mentioned in the motivation section caches the size of the image entity. • P ROTECTION Pro X Y checks if the caller has access to access to a request. • S UB J E C T (G R A P H i C) - The shared interface defines the RealSubject and P RO X Y, which can be used in any of any RE A L S UB J E C T can use P RO x Y. • R e a L S UB J E C T (I M A g E) - Defines the entities represented by P R O X Y. 7. Collaboration • The agent forwards the request to R e a L S UB J E C t at appropriate time according to its species. 8. Effects P R O X Y mode Introduces a certain degree of indirectibility when accessing objects. According to the type of agent, there are various uses of additional indirectness: 1) Remote Proxy can hide the fact that an object is present in different address space. 2) Virtual Proxy can be optimized, for example, to create an object as required. 3) Protection Proxies and Smart Reference are allowed to have some additional internal processing (Housekeeping Task) when accessing an object. The P R O X Y mode can also hide the user's optimization method called C O P Y - O N - W R I T E, which is related to the object being created as needed. Copy a huge and complex object is a big overhead, if this copy is not modified, then these overheads are not necessary. Delay this copy with a proxy, we can ensure that it will only be copied only when this object is modified. The entity must be referenced to the entity when implementing C O P Y - O N - W R I TE. The copy agent will only increase the reference count. Only when the user requests a modification of the implementation of the entity, the agent will really copy it. In this case, the agent must also reduce the reference count of the entity. This entity will be deleted when the number of references is zero. C O P Y - O N - WR I T E can greatly reduce the overhead of copying large entities. 9. Realize Chapter 4 Structured Model 1 3 9
P RO X Y mode can take advantage of the following language features: 1) Overloaded C in C supports overload operators ->. Overloading this operator allows you to perform some additional operations when you cancel a reference to an object. This can be used to implement certain types of agents; the role of the agent is like a pointer. The following example shows how to use this technology to achieve a voidger called I m a g e p T r. The overloaded-> and * operator uses L O a D i m a g e to return _ I m a g e to its caller (if necessary). This method allows you to call I m a g e operation through the I m a g e P T R object, and save these operations as a part of the I m a g e pt R interface. Note that the I m a g e agent here play a pointer, but does not define it as a pointer to I m a g e. This means you can't use it as a real pointing to i m a g e. Therefore, the user should distinguish the I m a g e object and the I m a g e P T R object when using this method. The heavy-duty member access operator is not a good way for every agent. Some agents need to clearly know which operation calls, the method of overloading operators is in this case. Considering the example of the virtual genus mentioned in the top section, the image should be loaded at a specific time - that is, in the design mode: the basis for object-oriented software
D R a W is called when it is called - instead of being loaded with this image. This distinction cannot be made by overloading access operators. In this case we can only manually implement each agent operation, forward the request to the entity. As shown in the sample code, these operations are very similar. In general, all operations must be legally legal, whether the original object exists before the request is forwarded to the entity. But repeatedly writing these codes is cumbersome, so we generally generate it with a preprocessor program. 2) A HO O K method can be used to automatically forward requests using D O E S N o T L t a L K in S M a L t a Lk. When the user sends a message to the recipient, this recipient does not have a related method, and the S a M L is called method DOESNOTUNDERSTAND: AMESSAGE. The P R O X Y class can redefine D O E S N O T U N D E R S T A N D to forward this message to its entity. In order to ensure that a request is truly forward to the entity, instead of silent and inferior agents, we can define a P R O x Y class that does not understand any information. S m a ll t a lk defines a P R O X Y class without any superclasses to achieve this. The main disadvantage of D O E S N o T: Most S M A L T A L K systems have some special messages directly controlled by virtual machines, and these messages do not cause usual way to find. The only symbol that is usually implemented with O B J E C T (so that it can affect the agent) is the constant operation = = =. If you are ready to use D O E S N o T U N D E R S T a N D: To implement P R O X Y, you must design around this issue. The identification of the agent does not mean the identification of true entities. D O e s N o T U N d: Another disadvantage is that it is mainly used as an error handling instead of creating a proxy, so it is generally not very fast. 3) Proxy does not always need to know the type of entity. If the P RoxY class can process its entity completely through an abstract interface, there is no need to generate a P RoxY class for each R Eal S ubject class; P Roxy can process all R eal s ubject class. However, if P R O X Y wants to instantiate RealSubjects (e.g., in Virtual Proxy), they must know the specific class. Another implementation problem involves how to reference it before instantiate the entity. Some agents must reference their entities, no matter whether it is on the hard disk or in memory. This means they must use some object identifiers that are independent of the address space. In the destination section, we use a file name to implement this object identifier. 10. Code Example The following code implements two proxy: Virtual Proxy described in the destination section, and the P R O X Y implemented with D O E S N o T u n d: implemented P r o x y. 1) The Virtual Proxy Graphic class defines an interface for graphic objects. Chapter 4 Structure Model 1 4 1
This technique is used in the implementation of distributed objects (especially class N x P R O X Y) in N e x T S T E P [A D 9 4]. N e x T S TEE P M composition is F O R W A R D, which redefines the F O R W A R method. I T E R A T O R Mode (5. 4) describes another type of P R O X Y. The I m a g e achieves the G R a P H i C interface to display image files. The I m a g e redefines the size of the H a N D L E M O U S E to adjust the size of the image to the user can interact. I Mage P Roxy and I Mage have the same interface: The constructor saves local copies of the file name of the store, and initializes _ extent and _ image: If possible, the implementation of G et e xtent returns the size of the cache; Otherwise loading images from the file. D R a W is used to load images, and H A N D E L M O U S e forwards this event to the actual image. 1 4 2 Design Mode: The basic S A V e operation that can be used to object-oriented software will save the cached image size and file name in a stream. L O a d gets this information and initializes the corresponding member function. Finally, suppose we have a class TE X T D O C U m e n t to include G R a P H i C object: We can insert I M A G E P R O X Y into the text file in the following way. 2) Use D O E S N o T U N D E R S T a N D PROXY in S M A L T A Lk, you can define a class that is N i L, while defining the DoesNotunderstand: method processing message, which builds some universal agents. In the following procedure we assume that the agent has a R E a L S UB J E C T method, which returns its entity. In I M A G E P R O X Y, the method will check if I M A G E has created it, and create it when necessary, and finally returns I m a g e. It uses Perform: WITHARG U m E N T S: to perform those messages that are retained in the entity. D O E S N O T U N D: The parameter is an example of M E S S A G E, which represents a message that the agent cannot understand. Therefore, the agent first determines the existence of the entity before forwarding the message, and thus responds to all messages. One advantage of D O E S N O T U N D E R S T a N D: It can perform any processing. For example, we can generate a Protection Proxy in this way, which specifies a collection of messages that can be accepted, and then define the following method to define the following method. Chapter 4 Structure Model 1 4 3
Almost all classes are ultimately as their superclass with O b J E C T (object). So this sentence is equal to "Defining a class, its superclass is not O B J E C T." This method checks its legitimacy before forwarding a message to the entity. If it is not legal, send Error: Give the agent unless the agent defines E R R O R:, this will generate an unlimited cycle. Therefore, the definition of E R R O R: should be copied from the O B J E C T class with all the methods used. 11. Examples of Virtual Proxy from the Dynamic PROT II are constructed from the text building block class of E t . N e x T S t e p [A D D 9 4] Using an agent (class N x P R O X Y) as a local representative of the distributable object, the server creates a proxy for these objects when the client requests a remote object. After receiving the message, the agent encodes the message and its parameters and passes the encoded message to the remote entity. Similarly, entities encodes all returned results and returns them to N x P R O x Y objects. McCullough [MCC87] discusses the problem of accessing remote objects with proxy in S M A L L K K. Pascoe [PAS86] discusses how to control the side effects called by the "Packaging" (E N C A P S Ut T O R) and perform access control. 12. Related Mode A D A P T E R (4. 1): Adapter A D A P T E R provides a different interface for the object it adapted. Instead, the agent provides the same interface as its entity. However, agents for access protection may reject the operation of the implementation of the entity, so its interface is actually just a subset of the entity interface. D E C O R A T O R (4): Although the implementation portion of D e C O R A T O R is similar to the agent, the purpose of DE C O R A T O R is different. D e c O R A T O R adds one or more functions to the object, and the agent controls access to the object. The achievement of the agent is similar to the implementation of D e C O R A T O R, but there is a difference in similar extent. The implementation of Protection Proxy may be similar to DE C O R A T O R. On the other hand, Remote Proxy does not include direct reference to the entity, but only an indirect reference, such as the host ID, local address on the host. "Virtual Proxy starts using an indirect reference, such as a file name, but eventually Get and use a direct reference. 4.8 Structural mode Discussion You may have noticed similarity between structural modes, especially the similarity between their participants and collaboration. This may be because structured mode depends on the same small language mechanism collection construct code and object: single inheritance and multiple inheritance mechanisms for class-based mode, while the object combination mechanism is used for object mode. However, these similarities mask the disagree diagrams of these modes. In this section, we will compare these structural patterns so that you have aware of their respective advantages. 4.8.1 Adapter and Bridgea D A P T E R (4. 1) Mode and B R I D G E (4. 2) mode have some common features. They provide another object to some extent, which is conducive to the flexibility of the system. They all involve a forward request from one interface other than itself. The differences between these modes are mainly their respective purposes. The A D a P TER mode is mainly to solve the problem of mismatch between two existing interfaces. It does not consider how these interfaces are implemented, and they don't consider how they may evolve. This approach does not need to be redesigned for any of two independently designed classes, and they can work together.
Another 1 4 4 Design mode: can be used for object-oriented software
On the one hand, B R i D g E mode bridges the abstraction interface with its (possibly multiple) implementation portions. Although this mode allows you to modify the class that implements its class, it still provides users with a stable interface. B R i D g E mode will also adapt to new implementation when system evolution. Because of these differences, A D A P T ER and B R I D GE mode are often used in different stages of the software life cycle. When you find that two incompatible classes must work simultaneously, it is necessary to use A D A P T E R mode, which is generally to avoid code repetition. This coupling is unforeseen. In contrast, the user of B R i D g e must know in advance: an abstraction will have multiple implementations, and both abstraction and implementation are independently evolved. A D A P TER mode is implemented after the class has been designed; and the B R I D GE mode is implemented before the design class. This does not mean that the A d a p t er mode is not as B R i D g E mode, just because they have been targeted. You may think F A C A D E (see F A C A D E (4. 5)) is an adapter for another set of objects. But this explanation ignores a fact: that is, F A C A D e defines a new interface, and A D A P TE R is multiplexed with an original interface. Remember, the adapter works two existing interfaces, rather than defining a new interface. 4.8.2 Composite, Decorator and ProxyC O M P O S i T E (4. 3) Mode and D E C O R A T O R (4) Mode have similar structural diagrams, which indicates that they organize variable-variable objects based on the recursive combination. This work may make you think that D e c O R A T O R object is a degraded C O m P O S i TE, but this view does not understand D e c O R A T O R mode points. Similar points are only in recursive combination, the same, because the purpose of these two modes is different. Decorator aims to add responsibilities to objects without generating subclasses. This avoids static implementation of all functional combinations, resulting in a sharp increase in subclasses. C O m P O S I TE is a different purpose, which is intended to construct classes, allowing multiple associated objects to be handled in a unified manner, while multiple objects can be treated as an object. It focuses is not to be modified, but Although their purpose is very different, it has complementaryness. Therefore, Composite and D E C O R A TO-mode are usually used in common. When designing these two modes, we do not need to define new classes, just insert some objects together to build applications. At this time, there will be an abstraction class in the system, which has some C O m P O S I T E subclass and D E C O R A T O R subclass, and some implementation of the basic build module. At this point, Composites and D E C O R A T O R will have a common interface. From the perspective of D E C O R A T O R, C O m P O S I T E is a C O N C R E T E C O M P O N E N. From the perspective of the C O m P O S I T E-mode, D E C O R A T O R is a L E A F. Of course, they don't have to use at the same time, as we see, their purpose is very different. Another mode similar to the D e C O R A T O R mode is P R O X Y (4. 7). Both modes describe how the objects provide some indirect references, the implementation of the Proxy and D E C O R A T O R objects reserve a pointer to another object, which sends a request to this object. Again, however, they have different design purposes.
Like D E C O R A T O R mode, the Proxy mode constitutes an object and provides a consistent interface for the user. However, different from D e c O R A T O R mode is that the PROXY mode cannot be dynamically added or separated, which is not designed for recursive combination. Its purpose is to provide an alternative to this entity when accessing an entity is inconvenient or does not meet the needs, for example, an entity is on a remote device, and an access is limited or an entity is persistent. In P R O X Y mode, the entity defines a key function, and P R O X Y provides (or rejected) access to it. In D E C O R A T O R mode, the component only provides partial functions, and one or more D e C O R A T O R is responsible for completing other functions. The D e C O R A T O R mode is suitable for compiling all the functions of the object when it is not possible (at least inconvenient). This openness makes Chapter 4 Structure Model 1 4 5 The recursive combination becomes an essential portion in D e c O R A T O R mode. This is not the case in the P R O X Y mode, because the P R O X Y mode emphasizes a relationship (the relationship between P R O X Y and its entity), which can be static expression. These differences between patterns are very important because they have a solution to some specific regular problems in an object-oriented design process. But this does not mean that these modes cannot be used in conjunction. It is conceivable to have a P R O X Y-D E C O R A T O, which adds a function to the P R O X Y, or a D e c O R A T O R- P R O X Y is used to modify a remote object. Although this mix may be useful (we have no ready-made examples in hand), they can be divided into some useful patterns. 1 4 6 Design mode: can be used for object-oriented software
