Chapter 1 introduces object-oriented software, and more difficult-oriented software is more difficult. You must find related objects to classify them, and then define the interfaces and inheritance hierarchies to establish the basic relationship between objects. Your design should be targeted against the problem of your head, and also has sufficient versatility for future issues and needs. You also want to avoid duplicate design or do your designs as little as possible. Experienced object-oriented designers will tell you that you have to get a reuse and flexible design, even if it is not unlikely to be very difficult. A design is often reused several times before the final completion, and it has been modified every time. Experienced object-oriented designers can indeed make a good design, and novices face many choices, always call for non-proportional object technology used. Novice takes a long time to understand how the object-oriented design is going. Experienced designers obviously know what some novices don't know, what is this? The in-line designer knows: not to solve any problems, you have to start with your head. They are more willing to reuse the previously used solutions. When you find a good solution, they will be used over and over again. These experiences are part of their way. Thus, you will see an object (c o m m u n i c a t i n go b j e c t) and the repeating pattern classes communicate with each other in many object-oriented systems. These patterns solve specific design problems, making the object-oriented design more flexible, elegant, and final reuse. They help designers have established new design on the previous work, multiplexing the designs of previous success. A designer familiar with these modes does not need to discover them again, and they can immediately apply them in design issues. The following categories can help indicate this. Novelists and script writers rarely start designing plots. They always follow some models that have existing models, like the "Tragic Hero" model ("Mike White", "Hamlet", "Romantic Novel" model (there is countless romantic novel). Similarly, object-oriented designers also follow some modes, like "object representation status" and "modified objects to facilitate you can easily add / delete properties". Once you know the pattern, many design decisions have naturally occurred. We all know the importance of design experience. How many times have you been have to have this feeling - you have already solved a problem but is not exactly what is it or how to solve it? If you can remember the details of the previous problem and how to solve it, you can multiplex the previous experience without re-discovered it. However, we don't have a good record of software design experience that can be used by others. The purpose of this book is to record the design experience of object-oriented software as a design pattern. Each design pattern is systematically named, interpreted, and evaluated an important and repeated design of an object-oriented system. Our goal is to record design experience in the form of people can effectively utilize. In view of this purpose, we have written some of the most important design patterns and present them in the form of catalogation. The design pattern makes people more easily and easily reuse successful design and architecture. It will also make new system developers easier to understand their design ideas. Design patterns help you make a choice for system multiplexing to avoid designing damage to system reuse. By providing an explicit class and an objective relationship and the potential connection specification, design patterns can even improve the validity of document management and system maintenance of the system. In short, design patterns can help designers complete system design faster. The design patterns involved in this book do not describe new or unconfirmed designs, and we only include those successful designs that have been used multiple times in different systems. Most of these designs have no document records, which are derived from informal communication in the object-oriented design, or some part of some successful object-oriented systems, but for newcomers These things are very difficult to learn. Although these design do not include new ideas, we use a new, easy-to-understand way to read them, namely: several group design modes with unified formats.
Although the book covers more content, the design model discussed in the book contains only a portion of the design expert. There is no pattern related to concurrency or distributed or real-time programming, and there is no model for specific applications. This book is not prepared to tell you how to construct user interfaces, how to write a device driver or how to use object-oriented databases, these aspects have their own mode, and the catalog of these patterns is also very meaningful. 1.1 What is design mode Christopher Alexander said: "Every pattern describes a problem that has been repeated around us, as well as the core of the solution. This way, you can use the scheme again and not to do Repeat labor "[AIS 7 7, page 1 0]. Although A l e x a n d e r refers to urban and architectural models, his thoughts are equally applicable to object-oriented design patterns, just in object-oriented solutions, we use objects and interfaces instead of walls and doors and windows. The core of the two types of modes is to provide a solution for related issues. In general, a model has four basic elements: 1. Pattern Name A help name, which uses one or two words to describe the problem, solutions and effects. Name a new mode adds our design vocabulary. The design pattern allows us to design at higher abstractions. Based on a pattern vocabulary, we can discuss the model between our own and colleagues and use them when writing documents. The model name can help us think, it is easy to exchange design ideas and design results with others. Finding the right model name is also one of the difficulties in our design model cataloging. 2. Problem describes when the mode should be used. It explains the presence of design problems and problems, which may describe specific design issues, such as how to use object representation algorithms. It is also possible to describe a class or object structure that causes unreflexible design. Sometimes the problem part will include a series of prerequisites that must be met. 3. Solution describes the composition of the design, the interrelationships between them and their respective responsibilities and collaborative methods. Because pattern is like a template, it can be applied to a variety of different occasions, so the solution does not describe a specific and specific design or implementation, but provides an abstract description of design problems and how to use a combination of elements with general meaning (class) Or object portfolio) to solve this problem. 4. Consequences describe the effects of the mode application and the problem of using the model. Although we describe design decisions, it is not always mentioned in the mode effect, but they are important for evaluating design selection and understanding of use models. Most software effects focus on the measurement of time and space, and they also express language and implementation issues. Because multiplexing is one of the elements of object-oriented design, the mode effects include its impact on the flexibility, expandability or portability of the system, explicitly listing these effects to understand and evaluate these patterns. The difference in starting point will produce what is mode and what is not mode understanding. A person's mode may be only a basic construction component for another person. In this book we will discuss models at a certain abstraction level. "Design Mode" does not describe the design of the linked list and H A S H, although they can be encapsulated by classes, they can be reused; they do not include those complex, specific areas. Design for the entire application or subsystem. The design pattern in this book is a description of the objects that are used to solve the class and mutual communication of general design issues in a particular scenario. A design pattern named, abstract and determined a main aspect of a general design structure, which can be used 2 design mode: can be used for object-oriented software
To construct a reused object-oriented design. The design pattern determines the included classes and instances, their roles, collaboration methods, and duties assignments. Each design pattern is centrally located for object-oriented design issues or design points, which describes when using it, whether it can be used in other design constraints, and how to use it. Since we finally implement design, design mode also provides C and S m a l t a l k sample code to clarify its implementation. Although design patterns are described in object-oriented design, they are all based on actual solutions, and the implementations of these programs are mainstream-oriented object-oriented programming languages such as SmallTalk and C , not process language (P ASCAL, C, A Da Object-oriented language (CLOS, D YLAN, S ELF), or more dynamic characteristic. We have selected SmallTalk and C from a practical perspective, because we have accumulated many experiences in these languages, and they have become more and more popular. The choice of programming language is very important, it will affect people's understanding of the starting point. Our design model uses the language characteristics of the SmallTalk and C layers, which actually determines which mechanisms can be easily implemented, and which cannot be. If we use process language, it may include design patterns such as "inheritance", "encapsulation" and "polymorphism". Accordingly, some special object-oriented languages can directly support some of our modes, such as C L O S support multi-method (M u L T i - M e T H o D) concept, which reduces the necessity of VI S i t o R mode. In fact, S M A L t a l k and c have sufficient differences to illustrate some languages that are more prone to some languages than another language (see 5.4 Iterator mode). 1.2 Design Mode in SMALLTalk MVC In S M A L T A L K - 8 0, the model / view / controller (M O D E L / VI E W / C O N T R O L1 R) The ternate group (M v c) is used to build the user interface. Designing design patterns through MVC will help us understand the meaning of the term "mode". M v c includes three types of objects. Model M O D e l is an application object, and the view VI e w is its representation on the screen, and the controller C O N T R O L ER defines the response method of the user input to the user input. Without M v C, user interface design tends to mix these objects, while M v C separates them to improve flexibility and reuse. M V C separates views and models by establishing a "Order / Notification" protocol. The view must ensure that its display correctly reflects the status of the model. Once the data of the model changes, the model will notify the relevant view, each view, which is refreshed, and the opportunity is refreshed. This approach allows you to provide a different form of view expressions for a model, and can create new views for a model without rewrite the model. The figure below shows a model and three views (for simplicity, we will omit the controller). The model contains some data values, and the view displays this data via a spreadsheet, a histogram, and a pie chart. When the data of the model changes, the model notifies its view, and the view will communicate with the model to access these data values. Chapter 1 Introduction 3
On the surface of the view model, this example reflects the design separation of the view and model, however, this design can also be used to solve more general problems: Separate objects, so that a change in object can affect other objects, and this object is not Need to know the details of those affected objects. This more general design is described in O b S E R V E R (5. 7) mode. Another feature of M V C is that the view can be nested. For example, the button control panel can be implemented with a complex view of a nested button. The user interface of the object viewer can be composed of nested views, which can be multiplexed to the debugger. M v c supports nested views with the subclass of VI E W class-C O m P O s i t e vi e w Class. C O m P O S i TE E VI EWA object behavior is similar to the VI E W class, a combined view can be used for any view available, but it contains and manages nested views. The above example reflects the design of the combined view and its components equally, the design is also applicable to more general problems: a group of objects is used as a group and the group object is used as an object. This design is described as a C OMPOSITE (4. 3) mode, which allows you to create a class hierarchy, some subclasses define atomic objects (such as b utton) and other classes define a combination object (C OMPOSIG VI EW), These combinations are more complex objects that are combined by atomic objects. M v c allows you to change the view to the user's input to the user's response to the user without changing the appearance of the view. For example, you may want to change the view to the keyboard, or you want to use the pop-up menu instead of the original command key. M V C encapsulates the response mechanism in the C O N T R O L1 R object. There is a class hierarchy of C O N T R O L E R that makes it easy to properly change the original C O N T R O LE R to create a new C O N T R O L1 E R. VI E W implements a specific response policy using an example of the C O N T R O LE R subclass. To achieve different response policies, just replace them as long as you use different types of C O N T R O L. You can change the response of the VI E W to the user input by changing the C O N T R O L E R of VI E W by changing the C O N T R O L E R of VI E W. For example, a VI E W can be banned from receiving any input, simply gives it a C O N T R O L1 R that ignores the input event. The VI E W - C O N T R O L E R relationship is an example of the S T R A T E G Y (5. 9) mode. A strategy is an object of an expression algorithm. When you want to static or dynamically replace an algorithm, or you have a lot of different algorithms, or the algorithm contains the complex data structure you want to encapsulate, the policy mode is very useful. M v C also uses other design patterns, such as: Factory Method (3.3) for specifying a view default controller and D E C O R A T O R (4. 4) used to increase view scrolling. However, the main relationship between M v C is given by the three design patterns of O b S E R V, C O M P O S I T E and S T R A T E G Y. 1.3 Description Design Mode How do we describe design patterns? Although the graphic symbol is very important, it is still not enough, they just simply record the results of the design process as the relationship between classes and objects. In order to achieve design multiplexing, we must simultaneously record the decision process, selection process, and trade-off process. Specific examples are also important, they let you see the actual design. We will describe design patterns in a unified format, each of which is divided into several parts according to the following templates. The template has a unified information description structure that helps you learn, compare and use design patterns easier.
The model name and classification mode are simply described in the nature of the pattern. A good name is very important because it will become part of your design vocabulary. The classification of the pattern reflects the solution we will introduce in 1. 5. The intention is to answer the simple statement of the following questions: What is the design pattern? What is its basic principles and intentions? It declares 4 design mode: What kind of specific design is determined for the basis of object-oriented software? Other names of the alias mode. Motivation to illustrate a design problem and how to use classes in the mode to solve the specific scenarios of this issue. This scenario will help you understand the description of the pattern more abstract. What is the design mode? What is the poor design for this mode to improve? How do you identify these situations? The structure is graphically describing the class in the pattern based on the representation of object modeling techniques (O m t) [R b P 9 1]. We also use interactive diagrams [J C JO 9 2, B O O 9 4] to explain the request sequence and collaborative relationship between the objects. Appendix B detailed these representations. Participants refer to the class and / or objects in the design mode and their respective responsibilities. How can participants in collaborative models work together to achieve their duties. How does the effect model support its goals? Use the effect of the model and the we need to do it? What are the system structure changes independently? Some tips, technical points, and defects that need to be known when implementing the implementation mode, and whether there are certain problems specific to implementing language. The code example is used to explain how to implement the code segment of this mode with C or S M A L T A Lk. Examples of the model found in the actual system are known. Each mode includes at least two instances of different fields. What are the modes related to this mode? What is important and different? What other modes should this be used? The background information provided by the appendix will help you understand the mode and discussions about the mode. Appendix A gives the list of terms we use. Appendix B, which has been mentioned earlier, gives a variety of representations, and we will briefly introduce them in future discussions. Finally, Appendix C gives the source code of each of our basic classes used in the example. 1.4 Design Mode Catalogs Coping from Chapter 3 The mode directory contains 2 3 design patterns. Their names and intentions are listed below so that you have a basic understanding. The chapter in which the brackets in each model is marked (our whole book will follow this agreement). Abstract Factory (3. 1): Provides an interface that creates a series of related or interdependent objects without specifying their specific classes. Chapter 1 Introduction 5
A D A P T ER (4. 1): 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. B R I D g e (4): Separate the abstraction portion with its implementation, so that they can change independently. B U I L D E R (3. 2): Separate a complex object with its representation, so that the same construct can create different representations. Chain of Responsibility (5. 1): Couples between the requesting senders and recipients, and make multiple objects have the opportunity to handle this request. Connect these objects into a chain and deliver the request along this chain until there is an object to handle it. C O m M A N D (5. 2): Package a request into an object so that you can use different requests to parameterize the customer; queuing or logging the request log, and supports the cancel operation. C O M P O S I T E (4. 3): Combine the object into a tree structure to represent a "portion-overall" hierarchy. C O M P O S I makes the customer consistency for the use of a single object and composite object. D E C O R A T O R (4. 4): Dynamically add some additional duties to an object. In terms of expansion, D E C O R A T O R is more flexible than generated subclasses. F A C A D (4. 5): Provides a consistent interface for a set of interfaces in a subsystem, defining a high-level interface, which makes this subsystem easier to use. Factory Method (3. 3): Define an interface to create an object, allowing the subclass to instantiate it. Factory Method delays a class of instantiation to their subclasses. F L Y W E G H T (4. 6): Use sharing technology to effectively support a large number of fine-grained objects. I N T E R P R E TET ER (5. 3): A representation of a language, defining a representation of its grammar, and defines an interpreter that uses this representation to explain the sentence in the language. I T E R A T O R (5. 4): Provides a method sequence accesses the individual elements in a polymerization, and does not need to expose the internal representation of the object. ME E D i a T O R (5. 5): Encapsulate a series of object interactions with a mediation object. The intermediaries make the objects need not be explicitly cited to each other, making them rolling, and can independently change the interaction between them. ME E M e N T O (5. 6): Capture the internal state of an object without damaging the encapsulation, and saves this state outside of the object. This will restore this object to the saved state in this later. O b S E R V E R (5. 7): Defines a one-to-many dependency between the objects so that all objects that depend on its object are notified when the status of an object changes and automatically refreshes. P R O T O T Y P E (3. 4): Specify the type of the object with prototype examples and create new objects by copying this prototype. P R O X Y (4. 7): Provide a proxy for other objects to control access to this object. S i N g l e t o n (3. 5): Ensure that a class has only one instance and provides a global access point access to it. S t a t e (5. 8): Allow an object to change its behavior when its internal state changes. Objects seem to modify the class it belongs. S T R A T E G Y (5. 9): Define a series of algorithms to encapsulate them, and allow them to replace each other. This model makes changes in algorithms can be independent of their customers.
Template Method (5. 1 0): Define the skeleton of the algorithm in an operation, delay some steps into the subclass. Template Method allows subclasses to redefine certain specific steps of the algorithm without changing the structure of an algorithm. 6 Design mode: The foundation VI S i T O R (5. 11) that can be used for object-oriented software is represented: represents an operation of each element acting in an object structure. It allows you to define new operations for these elements without changing the class of each element. 1.5 Tissue catalog design mode varies in different levels and abstractions. Due to many design patterns, we want to organize them in one way. This section will classify the design pattern to be referenced in our related modes. Classification helps to learn the model in the directory faster, and there is also a guiding role in finding new models, as shown in Table 1 - 1. Table 1-1 Design Mode Space Purpose Creating Structured Behavior Scope Factory Method (3.3) A Dapter (Class) (4. 1) I NTERPRETER (5. 3) Template Method (5.10) Object Abstract Factory (3.1) A Dapter (4. 1) Chain of Responsibility (5.1) B Uilder (3. 2) B Ridge (4. 2) C OMMAND (5. 2) P Rototype (3. 4) C omposite (4) I Teerator (5. 4) s Ingleton (3. 5) D ecorator (4) M EDIATOR (5) f ACADE (4. 5) M Emento (5. 6) f Lyweight (4. 6) O BSERVER (5. 7) P Roxy (4. 7) s Tate (5. 9) VI SITOR (5. 1 0) We classified according to two criteria (Table 1 - 1) . The first is the destination criterion, that is, the model is used to complete what work. The mode can be divided into three types (C R E A T I O N a L), structural (S t R u C T U R), or behavioral (B E H A V I O R A L), or behavioral (B E H A V I O R). Create mode is related to the creation of an object; a combination of structural mode processing classes or objects; behavioral mode is interactively interacts with how to interact with the class or object and how to assign responsibility. The second is that the scope criterion, the specified mode is mainly used for classes or for objects. The relationship between class mode processing classes and subclasses, these relationships are inherited, static, and it is determined at compile time. The relationship between the object mode processing objects, which can be varied, more dynamic. In a sense, almost all modes use the inheritance mechanism, so "class mode" only refers to the mode that focuses on the relationship between the processing class, and most of the models belong to the category of the object mode. Creating types of class mode Delayed the part of the object to the subclass, and the created object mode delays it into another object. The structural class mode uses the inheritance mechanism to combine classes, and the structural object mode describes the assembly method of the object. Behavioral class mode Use inheritors describing algorithms and control flows, and behavioral object mode describes how a set of objects collaborates to complete the tasks that a single object cannot be completed. There are other organization modes.
Some modes are often tied together, for example, C OMPOSITE often uses ITERATOR or VI SITORs; some modes are alternative, for example, p rototype is often used to replace A Bstrac TF ACTORY; Some modes Although the use of intentions, But the result of the result is very similar, for example, the structural diagram of C OMPOSITE and D Ecorator is similar. It is also a way to organize design modes to organize design patterns based on how they are cited to each other according to the "related mode" section. Figure 1 - 1 shows a graphical description of the pattern relationship. Chapter 1 Introduction 7 Obviously, there are many methods of organizing design patterns. From a multi-angle thinking pattern helps more in-depth understanding of their functions, differences, and applications. Figure 1-1 Relationship between design modes 1.6 Design mode How to solve the design pattern Design mode Use a variety of ways to solve problems that are often encountered by object-oriented designers. Here is given a few questions and how they are solved using design patterns. 1.6.1 Finding the appropriate object-oriented objects consists of objects, objects include data and processes to operate on data, process usually referred to as methods or operations. Objects Perform the appropriate operation after receiving the customer's request (or message). 8 Design mode: can be used for object-oriented software
Saving iterative status Creating a combination To Object Increase Responsibilities Change Outlook Change Content Definition Algorithm Step Dynamically Configuring Factory Factory Method To Implement Single Instance Single Instance Adding Operation Operation Share Combination Sharing Policy Definition Syntax Sharing Field Sharing Status Definition Traverse Definition Chain Avoiding Lag A child uses a combination to order the customer request is the only way to perform the operation of the object, and the operation is the only way to change internal data. Due to these limits, the internal state of the object is packaged, which cannot be directly accessed, and its representation is invisible to the outside of the object. The most difficult part of object-oriented design is to break the system into an object collection. Because many factors should be considered: packages, particle size, dependencies, flexibility, performance, evolution, reuse, etc., they all affect the system's decomposition, and these factors are usually conflictful. Object-oriented design methodology supports many design methods. You can write a problem description, pick out nouns and verbs, and create a corresponding class and action; or you can pay attention to the system's collaboration and responsibilities; or you can model the real world, then discover the analysis The object is transformed into the design. As for which method is best, there is no conclusion. Many objects designed come from the analysis model of the real world. However, the class obtained by the design results is usually not present in the real world, and some are low-level classes like arrays, while others are higher. For example, C O m P O S I T E (4. 3) mode introduces an abstract method of uniform objects that do not exist in the real world. Strictly reflecting the current model of the current real world does not produce systems that can also reflect future world. Abstractions in the design are crucial for flexible design. Design patterns help you identify abstraction and describe these abstract objects. For example, there is no existence in the actual reality of the description process or algorithm, but they are a key portion of the design. S TR A T E G Y (5. 9) mode describes how to implement interchangeable algorithm. S t a t e (5. 8) mode describes each state of the entity as an object. These objects are in the analysis stage, and even in the early days of the design phase, it does not exist in the design phase, and later, it is more flexible, and the reuse is better to explore them. 1.6.2 Deciding the particle size object of the object changes in size and number. They can represent anything from the hardware or the entire application. So how do we determine what an object should be? The design pattern tells this question very well. F A c a d e (4. 5) Mode describes how to use an object to represent a complete subsystem, F L Y W E I G H T (4. 6) mode describes how to support a large number of minimum particle size objects. Other design patterns describe a particular way to break an object into many small objects. Abstract Factory (3.1) and B U I L D E R (3. 2) Generate those objects that are responsible for generating other objects. The objects generated by VI S i T O r (5. 1 0) and C O m M a N D (5. 2) are specifically responsible for implementing requests to other objects or object groups. 1.6.3 Specifying each operation of the object interface object declaration specifies the operand, the object and the return value of the parameters, which is the so-called operation of the type (S I g n t u R e). The set of all operational profiles defined by the object operation is referred to as the interface of the object (I N T E R f A C e). The object interface describes a collection of all requests that the object can accept, and any requests in any matching object interface can be sent to the object. Type (TYPE) is used to identify a name of a particular interface. If an object accepts all the operations requests defined by the "Wi N D O W" interface, then we say that the object has the "Wi N D O W" type. An object can have many types, and different objects can share the same type. Some parts of the object interface can be portrayed in a type, while others can use other types of portrains. Two types of objects only need to share parts of the interface. The interface can contain other interfaces as a subset.
When a type of interface contains another type of interface, we say that it is another type of subtype (S u b t y p e), and another type is called its hypercarcies (S u p e R t y p e). We often say that the child type inherits its super-type interface. Chapter 1 Introduction 9
In an object-oriented system, the interface is a basic component. Objects can only communicate with external interfaces. If you do not pass objects, you cannot know anything about objects, and you cannot request an object to do anything. The object interface is separated from its functionality. Different objects can be implemented differently, that is, two objects with the same interface can have a completely different implementation. When the request is sent to the object, the specific operation caused is related to the request itself and associated with the acceptance object. Different objects that support the same request may have different implementations on the operation of the request. The request to the object and its corresponding operation is called dynamic binding (Dynamic Binding). Dynamic Binding refers to the request of the request until the running time is subject to your specific implementation. Thus, when you know any of the objects with the correct interface, you can write a general program that looks like some objects with this particular interface. Further, dynamic binding allows you to replace the same interface with each other at runtime. This replaceability is called polymorphism (P O L Y M O R P H I S M), which is one of the core concepts in an object-oriented system. Polymorphism allows customer objects only requires other objects to support specific interfaces, in addition to this assumptions are nearly nothing. Polymorphism simplifies the customer's definition, so that the objects are independent of each other and can dynamically change their relationships with each other at runtime. Design mode helps you define interfaces by determining the main components of the interface and the data type sent by the interface. The design pattern may also tell you what should not be included in the interface. ME E M E N T O (5. 6) mode is a good example, which describes how to encapsulate and save the inside of the object, so that the object can be restored to this state for a while. It specifies that the M e m e n t o object must define two interfaces: a restriction interface that allows customers to keep and copy M E M E N TO, and a privileged interface for storing and extracting the status of the M e m e n t o in only the original object. The design pattern also specifies the relationship between the interfaces. In particular, they often require some classes to have similar interfaces; or they have restrictions on some of the interfaces. For example, D E C O R A T O R (4. 4) and P R O X Y (4) Mode require that the interface of D e c O R A T O R and P R O X Y objects is consistent with the modified object and the delegated object. In VI S i T O R (5. 11) mode, the VI S i t O R interface must reflect all classes of the object accessible to V i s i t o r. 1.6.4 Describe the implementation of the object, we rarely mention how to define an object. The implementation of the object is determined by its class, the class specifies the internal data and representation of the object, which also defines the operation that the object can complete, as shown in the right. We describe a rectangle based on the representation of O m T, and the class name is represented by the black body. Operation is below the class name to represent a regular font. Any data defined by the class is below the operation. Between class names and operations and the operation and data are divided by horizontal lines. The return type and instance variable type is optional because we have not assume that you must use a static type of implementation language. Objects are created by instantiation, which is called instances of this class. When instantiating classes, the storage space is assigned to the internal data (consisting of instance variables), and the operation is associated with these data. Many similar examples of objects are created by instantiating the same class. The broken arrow line in the figure below indicates an object of another class, and the arrow points to the class of the object being instantiated. The new class can be defined by the existing class inheritance (Class Inheritance). As a subclass (S u b c L a s s) inherits the parent class 1 0 design mode: can be used for object-oriented software
(PARENT CLASS) When the subclass contains all the data and operations defined by the parent class. Sub-class instance objects contain all subclass and parent classes defined data, and they can complete all the operations defined by subclass and parent classes. We represent subclones in vertical lines and triangles, as shown below. The main purpose of abstract class is to define a common interface for its subclasses. An abstract class will delay the implementation of its part or all of the operations into the subclass, therefore, an abstract class cannot be instantiated. The operation defined in the abstract class is not implemented as an abstract operation. Non-abstract classes are called concrete classes. Subclasses can improve and redefine their parental operations. More specifically, the class can redefine the operation of the parent class definition (O V E R R I D e), redefine the resulting processing operation such that the subclass can take over the parent class. Class inheritance allows you to define new classes with simply extending other classes so that you can easily define a target family with similar functions. The class name of the abstraction is expressed in italics to distinguish between specific classes. Abstract operations are also represented by a bevel. The pseudo code that implements the operation is included. Mixin Class is a class that provides an optional interface or functionality to other classes. It cannot be instantiated as abstract classes. Mixing requires multiple inheritance, illustrated below. 1. The difference between the class inheritance and the interface inheritance of the comparison object (C L A S s) and the object type (T y p e) is very important. An object class defines how objects are implemented, and also define the internal state and operation of the object. However, the type of object is only related to its interface, the interface is a collection of requests that the object can respond. An object can have multiple Chapters 1 Introduction 1 1
Types, different types of objects can have the same type. Of course, the class and type of objects are closely related. Since the class defines the operations that the object can perform, the type of object is defined. When we say an object is an instance of a class, it means that the object supports the interface defined by the object. Class C and E I FF E L Language class specifies both the type of object and the implementation of the object. S m a ll t a l k program does not declares the type of variable, so the compiler does not check if the object type of the variable is the type of the type of variable. When sending a message, you need to check if the message recipient implements the message, but does not check if the recipient is an instance of a particular class. It is also important to understand the difference between class inheritance and interface inheritance (or child type). Class inheritance defines the implementation of another object based on an implementation of an object. In short, it is a sharing mechanism of code and representation. However, interface inheritance (or child type) describes when an object can be used to replace another object. Because many languages are not explicitly divided into these two concepts, it is easy to be confused. In C and E I FF E L, inherit the inheritance of the interface refers to the inheritance of the implementation. The standard method inherited in the interface in C is to inherit a class containing (pure) virtual member functions. The inheritance of the pure interface in C is close to the public inheritance, pure achievement or pureness inheritance is close to private inheritance. Inheritance in S M a L L t a lk refers to inheritance. As long as any class of instances support the operation of the variable value, you can secure these instances to variables. Although most of the programming language does not distinguish between interface inheritance and achievement of inheritance, people still treat them in use. S M a L L T A LK programmer typically uses subclasses as a variable type (although there are some well-known exceptions [C O O 9 2]), C programmers can manipulate the object through the type defined by the abstraction class. Many design patterns depend on this difference. For example, the object in Chain of Responsibility (5.1) mode must have a common type, but in general, they do not have public implementations. In C O M P O S I T E (4. 3) mode, the component defines a common interface, but C O M P O S I TEM usually defines a common implementation. C O m M A N D (5. 2), O B S E R (5. 7), S T A T E (5) and S T R A T E G Y (5. 9) are typically implemented as an abstract class of the interface. 2. Program the interface instead of the implementation programming class inheritage is a basic mechanism for extending application functions by multiplexing parent class. It allows you to quickly define new objects based on old objects. It allows you to inherit the most of the features you need from existing classes, so you can get new implementations without any cost. However, the re-use multiplex is only half of success, and the ability to inherit the definition of the same interface is also important (usually from abstract classes). why? Because polymorphism depends on this ability. When inherit is properly used, all classes exported from abstract classes will share the interface of the abstract class. This means that the subclass only adds or redefines the operation without hiding the parent class. At this time, all subclasses can respond to the request in the abstract class interface, so that the type of subclass is a subtype of an abstract class. Just depending on the interface defined in the abstract class, the object has the following benefits: 1) Customers do not need to know that they use the specific type of object, only the objects expected by the client. 2) Customers do not need to know what kind of object they use is implemented, they only have to know the abstraction class defined interface. This will greatly reduce the mutual dependencies between subsystem implementations, and also produce the following principles of object-oriented object-oriented design: programming for interface, not for implementation programming. Do not declare the variable as an instance object of a particular specific class, but allow it to comply with the interface defined by the abstract class. This is a common topic of this book design pattern.
When you have to instantiate the specific classes (ie, specify a specific implementation) in a place (ie, specify a specific implementation): the basis for object-oriented software (Abstract Factory (3.1), B Uilder 3. 2), Factory Method (3.3), P Rototype (3. 4) and S Ingleton (3. 5)) can help you. These modes provide different ways to create interfaces and implementation of transparent connections in different ways to instantiate. Creating a model Make sure your system is written in a way for interfaces, not for implementation. 1.6.5 The concept of using multiplexing mechanisms to understand objects, interfaces, classes, and inheritances is not difficult to most people, the key to the problem is how to use them to write flexible, multiplexed software. The design pattern will tell you how to do it. 1. The two most common technologies for the comparison of inheritance and combinations The two most common technologies in the object-oriented system are class inheritance and object portfolio. As we have explained, the class inherit allows you to define a class according to the implementation of other classes. This multiplexing of generated subclasses is often referred to as white-box reuse. The term "white box" is relative visibility: in the inheritance mode, the internal details of the parent class are visible to the subclass. Object portfolio is another multiplexing option other than class inheritance. New and more complex features can be obtained by assembling or combining objects. Object portfolio requires a combined object with a good definition interface. This multiplexing style is called Black-Box Reuse because the internal details of the object are invisible. Objects only appear in the form of "black box". Inheritance and combination have advantages and disadvantages. Class inheritance is static defined at compilation times and can be used directly because the programming language is directly supported by inheritance. Class inheritance can be more convenient to change the reuse. When a subclass is redefined instead of all operations, it can also affect the operation it inherit, as long as it is called the redefined operation in these operations. But the inheritance has some shortcomings. First, since the inheritance is defined at the compilation moment, it is not possible to change the implementation from the parent class inheritance at runtime. Worse, the parent class usually defines at least the specific representation of partial subclasses. Since the inheritance subclass reveals the details of its parent class, the inheritance is often considered "destroying the encapsulation" [S N y 8 6]. The implementation of the subclass with its parent class has such a close dependency, so that any changes in the parent class will inevitably lead to a substation change. When you need multiple subclasses, implementation dependence will generate some problems. If the implementation of inherits is not suitable for solving new problems, the parent class must rewrite or have been replaced by other more suitable classes. This dependency limits flexibility and ultimately limits the reuse. A available solution is to inherit the abstraction class because abstract classes usually provide less implementation. The object portfolio is dynamically defined by getting a reference to other objects. The combination requires objects to comply with each other's interface conventions, and require more careful definition interface, and these interfaces do not hinder you to use an object and other objects. This also produces good results: because the object can only be accessed through the interface, we do not destroy the encapsulation; as long as the type is consistent, the runtime can replace another object; further, because the object is based on The interface is written, so there is a small dependency on the implementation. Object portfolio has another effect on system design, that is, prioritizing the object portfolio helps you keep each class being encapsulated and is concentrated on a single task. Such classes and type inheritance hierarchy will remain smaller and is unlikely to grow into uncontrollable phenomenon. On the other hand, the object-based design is more objects (and fewer classes), and the behavior of the system will depend on the relationship between the objects rather than being defined in a certain class. This exports the second principle of our object-oriented design: priority use of object portfolios, rather than inheritance. Ideally, you should not create new components for the reuse. You should be able to use only object combination technology, Chapter 1 introduces 1 3
You can get the features you need by assembling existing components. But this is very small, because the collection of available components is actually not rich enough. Use inheritance reuse enables creating new components to be easier than the old components of the assembly. Thus, inheritance and object combination are often used. However, our experience shows that designers often use inheritance such multiplexing techniques. But the design of object combination technology has better reuse (or simpler). You will see repeatedly used object combination technology in the design mode. 2. Entrusted (D E L E G A T I O N) is a combination method that makes the combination have the same reuse capability [L i e 8 6, J z 9 1]. In the entrustment mode, there are two objects to participate in processing a request, accepting the requested object to delegate the agent (D E L E g A T e). This is similar to the parent class processing that the subclass will be delivered to it. When inheriting, the inherited operation is intended to reference the subject of accepting the request, and the C is passed through the T H I S member variable, and S M A L t a lk is passed by S e l F. In order to obtain the same effect, the entrustment method accepts the requested object to pass itself to the client (agent), enabling the object being entrusted, can reference the acceptable object. For example, we can save an instance variable of a rectangular class in the window class to proxy a specific operation of the rectangular class, such that the window class can be multiplexed by the rectangular class, without having to define a subclass of a rectangular class as inheriting. That is, one window has a rectangle instead of a window is a rectangle. The window now must explicitly forward the request to its rectangular instance, not what it must inherit the rectangle. The following figure shows that the window class delegates its A R E A operation to a rectangular instance. The arrow line represents a reference relationship between another class instance. The reference name is optional, this example is "R E C T a N g L E". The main advantage of the commission is that it is convenient for running to combine object operations and changing the combination of these operations. Assuming that the rectangular objects and circular objects have the same type, we only need to replace the rectangular object with a circle, the resulting window is circular. Entrusted with techniques that have been combined with software to obtain software flexibility, there is a shortcoming: dynamic, highly parameterized software is more difficult to understand than static software. There is also an inefficient problem, but it is more important to see people in the long run. It is a good choice only when the delegate is relatively simple and more complicated. It is difficult to give a rule that can tell you when you can use the rules that you can use. Because the efficiency of the entrusted can be related to the context and is also dependent on your experience. The entrustment is most suitable for a particular program, ie the standard mode. There are some modes to use delegate, such as S t a t e (5. 8), S T R A T E G Y (5. 9) and VI S I t O R (5. 11). In the S t a t e mode, an object will request to delegate the S t a t e object that describes the current state. In the S T R A T E G Y mode, an object will delegate a specific request to a description request to perform a policy, and an object will only have a state, but it can have many policies for different requests. The purpose of these two modes is to change the behavior of the entrusted object by changing the trusted object. In VI S i t O r, the operations on each element of the object structure are always delegated to the VI S I T O R object. Other modes are not available so much. ME E D i a t o R (5. 5) introduces a multi-design mode of communication between other objects between other objects: the basis for object-oriented software
Icon. Sometimes M e D i a t o r object simply forwards the request to other objects; sometimes it passes the request to your own reference, using true commission. Chain of Responsibility (5.1) handles requests along the object chain pass, sometimes, this request itself has a reference to accept the request object. At this time, the power is used. B R i D g e (4. 2) The implementation and abstract separation, if abstract and a particular implementation very matched, then this implementation can proxy an abstract operation. The entrusted is a special case of the object portfolio. It tells you that the object portfolio can be replaced by a code multiplexing mechanism. 3. Comparison of inheritance and parameterization Types Another functional multiplexing technique (not strictly object-oriented technology) is parameterized type, which is a class (a da, e i ff el) or Templates (C ). It allows you to specify all other types used in this type when defining a type. Unidentified types are provided in parameters. For example, a list class can perform parameterization with the type therewes. If you want to declare an I n t e g e R list, simply use the I n t E G ER type as a parameter value of the list parameterization type; declare a list of S t R I N g, just provide S TR I n g type as a parameter value. The implementation of the language will create a custom version of the corresponding list class template for a variety of element types. The parameterization type provides us with a third method other than class inheritance and object portfolio to combine behavior in object-oriented systems. Many designs can be implemented using any of these three technologies. Implementing a sorting routine that is operated as an element as a variable element, there may be a method: 1) implementing this operation (one application of the Template Method (5.10) via a subclass). 2) Implement the root of the object to the sort routine (S T R A T E G Y (5. 9)). 3) As the C template or the parameters of the A D A class, the name of the specified element is compared. These technologies have great differences. Object Combination Technologies allow you to change the combined behavior at runtime, but it has an indirectness, which is relatively inefficient. Inherit allows you to provide the default implementation of the operation and define these operations through subclasses. The parameterization type allows you to change the type used by the class. But inheritance and parameterization types cannot be changed at runtime. Which method is best, depending on your design and implementation constraints. There is no model in this book to be related to the parameterization type, although we use the parameterization type when customizing a mode C implementation. The parameterization type is completely unnecessary in language that is not performed like a compilation moment like S M a lt A L K. 1.6.6 Structure of Associated running moments and compile time A Structure of an object-oriented program running time is usually different from its code structure. The code structure is determined at the compilation time, which consists of a class fixed by inheritance relationship. The runtime structure of the program consists of a fast-changing communication object network. In fact, the two structures are independent of each other, trying to understand the other as if they try to understand the dynamics of the living ecosystem from static movement, plant classification. vice versa. Considering the difference between the object polymerization (A g g r E g A T I o N) and acquaintance (A C q u N c) and their representation of the compilation and running time. Aggregation means that an object has another object or is responsible for another object. Generally we call an object contains another object or part of another object. Aggregation means that the polymer object and its owner have the same lifecycle. Game means that an object only knows another object. Sometimes it is also known as "associated" or "reference" relationship. Accomplicated objects may request each other's operation, but they are not responsible for the other party. Accessibility is a relatively weak relationship, which only identifies more loose coupling relationships between objects. Chapter 1 Introduction 1 5
In the figure below, the ordinary arrow line represents acquaintance, and the tail has a diamond-shaped arrow line represents polymerization: aggregation and acquaintance are easily confused because they usually be implemented in the same way. In S m a ll t a lk, all variables are referenced by other objects, and there is no difference in the programming language. In C , aggregation can be implemented by defining a member variable indicating the true instance, but more typically defines these member variables as an instance pointer or a reference; each of them is also implemented in a pointer or reference. Fundamentally, is aggregation or acquaintance is determined by your intent rather than by explicit language mechanism. Although the difference between them is difficult to see in the structure of the compilation moment, these differences are still very big. The aggregation relationship is less and longer than the acquiring relationship; the acquisition relationship has a higher frequency, but sometimes only in one operation, it is more dynamic, so that it is more difficult to discriminate in the source code. The runtime structure and compile time structure of the program have such a big difference, and it is clear that the code is impossible to reveal all the system works. The operating time structure of the system is more affected by the designer, not the programming language. The relationship between objects and their types must be designed more carefully because they determine how the runtime program structure is good. Many design modes (especially those belonging to the object range) explicitly describe the difference in compilation time and runtime structure. C O m P O S I T E (4. 3) and D E C O R A T O R (4) are particularly useful for constructing complex runtime structures. O b S e r v E R (5. 7) is also related to the runtime structure, but these structures are difficult to understand for those who do not understand the mode. CHAIN OFR E S P O N S I B I L I T Y (5. 1) also produces communication modes that inherit cannot exhibit. In short, only understand the mode, you can clear the runtime structure in your code. 1.6.7 Design The key to supporting changes to achieve maximum reuse is that the prediestability of new needs and existing needs changes, requiring your system design to be improved accordingly. To design and adapt to this change, and have a robust system, you must consider what changes will change in its life cycle. A design that does not consider system changes may need to be redesigned in the future. These changes may be the redefine and implementation of the class, modify the customer and retest. Redesigning will affect many aspects of the software system, and the changes that have not been expected are always huge. The design pattern ensures that the system can change in a specific way, helping you avoid redesigning the system. Each design pattern allows a change in a system structure to be independent of other aspects, which will be more robust to a particular change in a particular change. Some general reasons for redesign, as well as design modes to solve these problems: 1) By explicitly designating a class to create an object When you create an object, the specified class will make you subject to a specific implementation rather than a specific interface. constraint. This will make future changes more complicated. To avoid this, you should create an object indirectly. Design mode: Abstract Factory (3.1), Factory Method (3.3), P R O T O T Y P E (3. 4). 2) The dependence on special operation When you specify a special operation for the request, the way the request is completed will be fixed. To avoid writing the request code, you will be able to easily change the response request at compile time or runtime. Design mode: CHAIN of Resposibility (5.1), C O m M A n D (5. 2). 3) For the external operating system interface and application programming interface (A P i) on different hardware and hardware 1 6 design mode: Object-oriented software
The aggregation example platform is different. Software depends on a specific platform will be difficult to port to other platforms, and even difficult to keep up with local platform updates. Therefore, it is important to limit its platform correlation when designing the system. Design mode: Abstract Factory (3.1), B R I D g E (4. 2). 4) Depending on the object representation or implementation knows how the object indicates that the customer may also need to change when the object is changed. Hide this information to customers can prevent chain changes. Design mode: Abstract Factory (3.1), B Ridge (4. 2), M Emento (5. 6), P RoxY (4. 7) 5) Algorithm-dependent algorithm is often expanded, optimized, and replaced when developing and reuse . Objects depending on a particular algorithm have to change when the algorithm changes. Therefore, it is possible to change the algorithm that should be isolated. Design mode: B Uilder (3. 2), I Teerator (5. 4), s Trategy (5. 9), Template Method (5.10), VI SITOR (5. 11) 6) is difficult to closely couple the coupling It is reused independently because they are interdependent. Tighten the system of the unit, change or delete a class, you must understand and change many other classes. Such a system is a difficulty of learning, transplanting, and maintaining. Loose coupling increases the possibility of a class itself, and the system is easier to learn, transplant, modify and expand. Design patterns use abstract coupling and hierarchical techniques to increase system loose coupling. Design mode: Abstract Factory (3.1), C O m M A N D (5. 2), F A C A D (4. 5), M E D I a T O R (5), Observer (5.7), CHAIN of Responsibility (5.1). 7) It is often difficult to customize the object by defining subclasses by generating subclasses. Each new class has a fixed implementation overhead (initialization, termination processing, etc.). Define subclasses also need to have an in-depth understanding of the parent class. To redefine an operation, you may need to redefine other operations. A redealmed operation may need to call inherited operations. And the sub-class method will lead to the class explosion, because even for a simple expansion, you have to introduce many new subclasses. The general object combination technology and the specific delegation technique are another flexible method of combined object behavior outside the inheritance. The new feature can be applied to the app by combining an object in a new manner instead of defining a subclass of the existing class. On the other hand, excessive use object combinations will make the design difficult to understand. In many design, you can define a subclass and combine it from the existing instance to introduce a customized feature. Design mode: B R I d g e (4), CHAIN of Responsibility (5.1), C O m P O S I t e (4. 4), D E C O R (4. 4), O B S E R (5. 7), S T R A T E G Y (5. 9). 8) It is not easy to modify the class Sometimes you have to change a class that is difficult to modify. Maybe you need a source code without (this situation for business class), or any change in the class will require a number of other subclasses. The design mode provides a way to modify the class in these cases. Design mode: A D a p T E R (4. 1), D E C O R A T O R (4), VI S I t O R (5. 11). These examples reflect the use of design patterns to help enhance software flexibility.
The importance of this flexibility depends on the software system you will be built. Let's take a look at the role of design models in the development of the following three types of main software: applications, toolboxes and frameworks. 1. Application If you want to build an application like a document editor or electronic tabulation software, its internal reuse, maintainability, and expandability are preferred. Internal reuse ensures that you will not do excessive design and implementation. Design mode improves internal reuse by reducing dependence. Loose coupling also enhances the likelihood of a class of objects and other multiple objects. For example, by isolation and package each operation to eliminate dependence on specific operations, Chapter 1 Introduction 1 7
You can make multiple an operation in different contexts becomes simpler. Eliminating the algorithm and representation depending on the same effect. When the design pattern is used to layers and restrictions on the platform dependence, they also make one application more maintainability. By displaying how to extend the class hierarchy and how to use object multiplexing, they enhance the easy expansion of the system. At the same time, the reduction in coupling is also enhanced. If a class rely moreover other classes, it is easy to expand this isolated class. 2. Toolbox An app often uses classes from one or more predefined class libraries called toolboxes (TO O L K I T). Toolbox is a set of associated, accessible classes, which provide general features. A typical example of the toolbox is a collection of lists, associated forms, stacks, etc., and C I / O stream library is another example. The toolbox does not enforce the application to adopt a particular design, they just provide functions for your application. The toolbox emphasizes the code multiplex, which is a "subroutine library" in an object-oriented environment. The toolbox design is much more difficult than the application design, because it requires many applications available and effective. Moreover, the toolbox designer does not know what application uses the toolbox and what special needs they have. In this way, avoid hypothesis and dependence becomes important, otherwise it will limit the flexibility of the toolbox, which in turn affects its applicability and efficiency. 3. Frame frame (F R a M e w o r k) is a set of mutually collaborative classes constituting a particular software to be multiplexed [D e U 8 9, J f 8 8]. For example, a frame can help build a graphic editor suitable for different fields, like art painting, music composing and mechanical C A D [V L 9 0, J O H 9 2]. Another frame may help you build compilers for different programming languages and target machines [J M L 9 2]. And again, maybe help you build financial modeling applications [B E 9 3]. You can define the application-related subclasses of the framework abstraction class to customize a framework to a specific application. The framework specifies the architecture of your application. It defines the split of overall structures, classes, and objects, the main responsibilities, classes and objects of each part, and the control process. The frame prefers these design parameters to facilitate application designers or implementors to focus their specific details of the application itself. The framework records common design decisions in its application. Thus the framework is more emphasized for design multiplexing, although the frame often includes a specific immediate subclass. This level of multiplexing results in the application and the inversion of controls between the software based on the software. When you use the toolbox (or a traditional subroutine), you need to write the body of the application and call the code you want to multiplex. And when you use a frame, you should use the main body of the app, write the code. You have to write operationally with a specific name and call agreement, but this will reduce the design decisions you need to make. Not only can you build applications faster, but also have similar structures. They are easy to maintain and the user seems more consistent. On the other hand, you have lost some freedom of creativity, because many design decisions do not require you. If the application is difficult to design, the toolbox is more difficult, and the framework is the most difficult. Frame designers must adventure the architecture to be adapted to all applications in this area. Any substantive modification of the frame design will greatly reduce the benefits of the framework because the framework is the most important contribution of the application lies in the architecture it defined. So the design of the design must be flexible and expandable as possible. Further, since the design is designed to be in the frame, the application of the frame interface is extremely sensitive. When the framework evolves, the application had to evolve. This makes loose coupling more important, otherwise a subtle change in the frame will cause a strong reaction. The main design issues just discussed are most important for frame design. A framework that uses design patterns rather than 1 8 Design mode: can be used for object-oriented software
The framework for design patterns is more likely to get high-level design multiplexing and code multiplexing. Mature frames typically use a variety of design patterns. The design pattern helps to get a framework architecture that can be applied to a variety of applications without redesign. When the framework is written to the document together, we can get another benefit [B J 9 4]. People who understand the design pattern can inspect the frame faster. People who don't even understand design patterns can also benefit from the structure of the production framework document. Strengthening documentation is important for all software, but the importance of the framework is particularly prominent. Learning to use the framework is often a process that must overcome many difficulties. Design modes cannot completely overcome these difficulties, but it can reduce the difficulty of frame learning by making more explicit instructions for the main elements of the frame. Because the mode and framework is similar, people often have the difference between them and whether they have different differences. Their most important difference is that the following three aspects: 1) The design mode is more abstract framework than the framework to indicate the code, and the design mode can only be represented as code. The power of the frame is that they can be written in the programming language, which can not only be learned, but also directly execute and reuse. The design pattern in this book needs to be implemented when each time is reused. The design pattern also explains its intentions, weighs, and design results. 2) Design mode is a typical framework for a smaller architecture element than frames including multiple design patterns, and it is notineted. 3) Framework than design patterns are always targeted in a particular application area. A graphic editor frame may be used in a factory simulation, but it will not be fault to think is an analog frame. The design pattern included in this book can almost use in any application. Of course, more special design patterns than our model are also possible (eg, distributed systems and concurrent program design modes), although these modes do not describe the architecture of the application as the framework. The frame is getting more common and important. They are the way the object-oriented system get the maximum reuse. Larger object-oriented applications will consist of a framework that cooperates with each other. Most of the design and code of the application will come from the framework used or affected. 1.7 How to choose the design mode This book has more than 2,0 design patterns for you to choose, to find out a pattern of specific design issues may still be very difficult, especially when you face a new set of modes, you are not very When you are familiar with it. Here, there are several different ways to help you find design patterns for your hand problem: • Consider how the design pattern solves the design problem 1.6 Discussion Design mode how to help you find the right object, determine the particle size of the object , Several other ways to specify object interfaces and design patterns to solve design problems. Refer to these discussions help you find the right mode. • The intent section of the browsing mode 1. 4 is listed in the intent (I N t e n t) of all modes in the directory. Read each mode intent to find one or more modes related to your problem. You can narrow your search range using the classification methods displayed in Table 1 - 1. • How to find each other in the study mode 1-1 shows the relationship between design patterns in a graphical way. Studying these relationships can guide you to get the right mode or mode group. • There are three chapters in the model mode classification description section of the research purposes, and one chapter introduces the creation mode, one chapter introduces the structural mode, one chapter introduces behavioral mode. Each chapter begins with an evaluation of the pattern introduction, and the comparison of a section and the end of the control. These sections allow you to have a common point and different points between the models with similar destination. • Check the reasons for redesign to see the chapter 1 of the chapter 1, which is not discussed from the "Design Supporting Change" section begins to discuss each chapter 1 9
Reasons, then look at whether your problem is related to them, then find out which patterns can help you avoid these factors that will result in redesign. • Consider which changes in your design are variable and focusing on reasons for redesign. It is not considered what will force your design to change, but consider what changes you want, but will not cause redesign. The most important point is the concept of encapsulation changes, which is the topic of many design patterns. Table 1 - 2 lists the design mode allows you to change independently, you can change them and will not lead to redesign. Table 1-2 Variable Aspects of Design Mode The variable aspects of design modes are variable, and the ABSTRACT FACTORY (3.1) is created for the product object family B Uilder (3. 2) on how to create a combination object Factory Method (3.3) Sub-class P ratotype (3. 4) to an instantiated class S Ingleton (3. 5) to a class of unique instance structures A dapter (4. 1) to the object's interface B Ridge (4. 2 Implementation of the object C OMPOSITE (4. 3) to an object structure and composition D ecorator (4. 4) to the object's duties, do not generate subclass f ACADE (4. 5) for a subsystem's interface f eiGHT (4. 6) For the storage overhead of the object P Roxy (4. 7) on how to access an object; the location behavior of the object CHAIN OF RESPONSIBILITY (5.1) checks when a request is satisfied with the object C OMMAND (5. 2) How to satisfy a request I NTERPRETER (5. 3) to a language grammar and explain I Teerator (5. 4) on how to traverse, access a polymeric element M ediator (5. 5) how to interact between the object, and Who intends to M EMENTO (5. 6) Which private information is stored in an object outside of this object, as well as when to store O BServer (5. 7), these objects are dependent on multiple objects, and these objects How to maintain consistent S Tate (5. 8) to the status of the object S... 5. Some step VI SITORs in the algorithm Template Method (5.1) on the algorithm can function on one. (Group) Operation on the object, but does not modify the class 1.8 how to use the design mode Once you have selected a design pattern, how do you use it? Here is a step-by-step approach to the design pattern. 1) Regionally browse the model special attention to its applicability part and the effect section, determine that it is suitable for you. 2) Back to study the structure section, participant partial and collaborative part Ministry ensures that you understand the class and objects of this mode and how they are associated. 3) Look at the code example section, see the specific example of this mode code form will help you implement mode. 4) Select the name of the mode participant so that they are in the application context meaningful design mode participant's name usually 2 0 Design mode: can be used for object-oriented software
