Design Patterns:glemente of Rousable Object-Oriented Software cope actory Method (121) Adapter (157) Interpreter (274) Template Method (360) Abstract Factory(99】 Adapter (157) Chain of Responsibility Builder (110) Bridge (171) (251) rototype (133) omposite (183) nd(263) singleton (144) Decorator (196) Iterator (289) Facade (208) Mediator (305) Flyweight (218)Memento (316) r0×y(233) Observer (326) State (338) Strategy (349) Visitor (366) Table 1.1:Design pattern space The second criterion,called scope,specifies whether the pattern applies primarily to classes or to objects.class patterns deal with relationships between classes and their subclasses.These relationships are established through inheritance.so they are static-fixed at compile-time.obiect patterns deal with Almost patterns"are those that focus on class relationships.Note that most patterns are in the object scope. Creational class patterns defer some part of object creation to subclasses,while Creational obiect patterns defer it to another obiect.The structural class pose classes,while the structural object patterns describe ways to assemble objects.The Behavioral class patterns use inheritance to describe algorithms and flow of control,whereas the Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone. There are other ways to organize the patterns.Some patterns are often used together osite is often used with Iterator or Visitor. Some patterns are alternatives:Prototype is often an alternative to Abstract Factory.Some patterns result in similar designs even though the patterns have different intents.For example,the structure diagrams of Composite and Decorator are similar. Yet another way to organize design patterns is according to how they reference each other in their "Related Patterns"sections.Figure 1.1 depicts these relationships graphically. 22
Design Patterns: Elements of Reusable Object-Oriented Software 22 Class Factory Method (121) Adapter (157) Interpreter (274) Template Method (360) Scope Object Abstract Factory (99) Builder (110) Prototype (133) Singleton (144) Adapter (157) Bridge (171) Composite (183) Decorator (196) Facade (208) Flyweight (218) Proxy (233) Chain of Responsibility (251) Command (263) Iterator (289) Mediator (305) Memento (316) Observer (326) State (338) Strategy (349) Visitor (366) Table 1.1: Design pattern space The second criterion, called scope, specifies whether the pattern applies primarily to classes or to objects. Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static—fixed at compile-time. Object patterns deal with object relationships, which can be changed at run-time and are more dynamic. Almost all patterns use inheritance to some extent. So the only patterns labeled "class patterns" are those that focus on class relationships. Note that most patterns are in the Object scope. Creational class patterns defer some part of object creation to subclasses, while Creational object patterns defer it to another object. The Structural class patterns use inheritance to compose classes, while the Structural object patterns describe ways to assemble objects. The Behavioral class patterns use inheritance to describe algorithms and flow of control, whereas the Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone. There are other ways to organize the patterns. Some patterns are often used together. For example, Composite is often used with Iterator or Visitor. Some patterns are alternatives: Prototype is often an alternative to Abstract Factory. Some patterns result in similar designs even though the patterns have different intents. For example, the structure diagrams of Composite and Decorator are similar. Yet another way to organize design patterns is according to how they reference each other in their "Related Patterns" sections. Figure 1.1 depicts these relationships graphically
Design Patterns:Elements of Rousable Object-Oriented Software clearly there are many ways to organize design patterns.Having multiple ways of thinking about patterns will deepen your insight into what they do,how they compare,and when to apply then Bgp】 Command State Template偏ted Factory Method Abstact Factory 一Facade Figure 1.1: Design pattern relationships WHow Design Patterns Solve Design Problems Design patterns solve many of the day-to-day problems object-oriented designers face,and in many different ways.Here are several of these problems and how design patterna so1 ve them】 已
Design Patterns: Elements of Reusable Object-Oriented Software 23 Clearly there are many ways to organize design patterns. Having multiple ways of thinking about patterns will deepen your insight into what they do, how they compare, and when to apply them. Figure 1.1: Design pattern relationships How Design Patterns Solve Design Problems Design patterns solve many of the day-to-day problems object-oriented designers face, and in many different ways. Here are several of these problems and how design patterns solve them
Design Patterns:Elements of Rousable Object-Oriented Software Finding Appropriate objects Object-oriented prograns are made up of objects.An object packages both data and the procedures that operate on that data.The procedures are typically called methods or operations.An object performs an operation when it receives a request (or message)from a client. Requests are the only way to get an object to execute an operation.Operations are the only way to change an obiect's internal data.Because of these restrictions. the object's internal state is said to be encapsulated:it cannot be accessed directly,and its representation is invisible from outside the object The hard part about object-oriented design is decomposing a system into objects. The task is difficult because many factors come into play:encapsulation, granularity,dependency,flexibility,performance,evolution,reusability,and on and on.They all influence the decomposition,often in conflicting ways. object-oriented design methodologies favor many ditrerent approaches.You can write a problem statement,single out the nouns and verbs,and create corresponding classes and operations.Or you can focus on the collaborations and responsibilities in your system.or you can model the real world and translate the obiects found during analysis into design.There will always be disagreement on which approach is best. Many objects in a design cor me from the analysis model.But object-oriented design often end up with classes that have no counterparts in the real world.Some of these are low-level classes like arrays.Others are much higher-level.For example, the Composite (183)pattern introduces an abstraction for treating oblects uniformly that doesn't have a physical counterpart.strict modeling of the real world leads to a system that reflects today's realities but not necessarily tomorrow's.The abstractions that emerge during design are key to making a design flexible Design patterns help you identify less-obvious abstractions and the objects that can capture them.For example,obiects that represent a process or algorithm don't occur in nature,yet they are a crucial part of flexible designs.The Strategy (349)pattern describes how to implement interchangeable families of algorithms The State (338)pattern represents each state of an entity as an object. These objects are seldom found during analysis or even the early stages of design:they're discovered later in the course of making a design more flexible and reusable. 24
Design Patterns: Elements of Reusable Object-Oriented Software 24 Finding Appropriate Objects Object-oriented programs are made up of objects. An object packages both data and the procedures that operate on that data. The procedures are typically called methods or operations. An object performs an operation when it receives a request (or message) from a client. Requests are the only way to get an object to execute an operation. Operations are the only way to change an object's internal data. Because of these restrictions, the object's internal state is said to be encapsulated; it cannot be accessed directly, and its representation is invisible from outside the object. The hard part about object-oriented design is decomposing a system into objects. The task is difficult because many factors come into play: encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, and on and on. They all influence the decomposition, often in conflicting ways. Object-oriented design methodologies favor many different approaches. You can write a problem statement, single out the nouns and verbs, and create corresponding classes and operations. Or you can focus on the collaborations and responsibilities in your system. Or you can model the real world and translate the objects found during analysis into design. There will always be disagreement on which approach is best. Many objects in a design come from the analysis model. But object-oriented designs often end up with classes that have no counterparts in the real world. Some of these are low-level classes like arrays. Others are much higher-level. For example, the Composite (183) pattern introduces an abstraction for treating objects uniformly that doesn't have a physical counterpart. Strict modeling of the real world leads to a system that reflects today's realities but not necessarily tomorrow's. The abstractions that emerge during design are key to making a design flexible. Design patterns help you identify less-obvious abstractions and the objects that can capture them. For example, objects that represent a process or algorithm don't occur in nature, yet they are a crucial part of flexible designs. The Strategy (349) pattern describes how to implement interchangeable families of algorithms. The State (338) pattern represents each state of an entity as an object. These objects are seldom found during analysis or even the early stages of design; they're discovered later in the course of making a design more flexible and reusable
Design Patterns:Elements of Rousable Object-Oriented Software Determining object Granularity objects can vary tremendously in size and number.They can represent everything down to the hardware or all the way up to entire applications.How do we decide what should be an object? Design patterns address this issue as well.The Facade (208)pattern describes how to represent complete subaystems as obiects,and the Flyweight (218)pattern deacribes how to support hug numbers of objects at the finest granularitiea Other design patterns describe apecitic ways of decomposing an object into objects.Abstract Factory (99)and Builder (110)yield objects whose only responsibilities are creating other obiects.visitor (366)and Command (263)vield obiects whose only responsibilities are to implement a request on another obiect or group of objects Specifying object Interfaces Every operation declared by an object specifies the operation's name,the objects it takes as parameters,and the operation's return value.This is known as the operation's signature.The set of all signatures defined by an object's operations is called the interface to the object.An object's interface characterizes the complete set of sts that can be sent to he object.Any quest that matches a signature in the object's interface may be sent to the object A type is a name used to denote a particular interface.We speak of an object as having the type "Window"if it accepts all requests for the operations defined in the interface named "Window."An object may have many types,and widely different objects can share a type.Part of an object'a interface may be characterized by on type, and othe parts by other types Two objects of the type n share parts of their interfaces.Interfaces can contain other interfaces as subsets We say that a type is a subtype of another if its interface contains the interface of its supertype.often we speak of a subtype inheriting the interface of its supertype Interfaces are fundamental in object-oriented systens.Objects are known oniy rough interface There is no way to know anything about an object。 to ask it to do anything without going through its interface.An object's interface says nothing about its implementation-different objects are free to implement requests differently.That means two objects having completely different implementations can have identical interfaces When a request is sent to an object,the particular operation that's performed depends on the request and the support identical requests may have different implementations of the operations 25
Design Patterns: Elements of Reusable Object-Oriented Software 25 Determining Object Granularity Objects can vary tremendously in size and number. They can represent everything down to the hardware or all the way up to entire applications. How do we decide what should be an object? Design patterns address this issue as well. The Facade (208) pattern describes how to represent complete subsystems as objects, and the Flyweight (218) pattern describes how to support huge numbers of objects at the finest granularities. Other design patterns describe specific ways of decomposing an object into smaller objects. Abstract Factory (99) and Builder (110) yield objects whose only responsibilities are creating other objects. Visitor (366) and Command (263) yield objects whose only responsibilities are to implement a request on another object or group of objects. Specifying Object Interfaces Every operation declared by an object specifies the operation's name, the objects it takes as parameters, and the operation's return value. This is known as the operation's signature. The set of all signatures defined by an object's operations is called the interface to the object. An object's interface characterizes the complete set of requests that can be sent to the object. Any request that matches a signature in the object's interface may be sent to the object. A type is a name used to denote a particular interface. We speak of an object as having the type "Window" if it accepts all requests for the operations defined in the interface named "Window." An object may have many types, and widely different objects can share a type. Part of an object's interface may be characterized by one type, and other parts by other types. Two objects of the same type need only share parts of their interfaces. Interfaces can contain other interfaces as subsets. We say that a type is a subtype of another if its interface contains the interface of its supertype. Often we speak of a subtype inheriting the interface of its supertype. Interfaces are fundamental in object-oriented systems. Objects are known only through their interfaces. There is no way to know anything about an object or to ask it to do anything without going through its interface. An object's interface says nothing about its implementation—different objects are free to implement requests differently. That means two objects having completely different implementations can have identical interfaces. When a request is sent to an object, the particular operation that's performed depends on both the request and the receiving object. Different objects that support identical requests may have different implementations of the operations
Design Patterns:glements of Rousable Object-Oriented Software that fulfill these requests.The run-time association of a request to an object and one of its operations is known as dynamic binding. Dynamic binding means that issuing a request doesn't commit you to a particula implementation until run-time.Consequently,you can write programs that expect an object with a particular interface,knowing that any object that has the correct interface will accept the request.Moreover,dynamic binding lets you substitute objects that have identical interfaces for each other at run-time.This ty knowy a polygrp ang key copcept in It lets a client othe objects beyond supporting a particular interface.Polymorphism simplifies the detinitions of clients,decouples objects from each other,and lets them vary their relationships to each other at run-time. Design patterns help you derine interfaces by identifying their key elements and the kinds of data tht ge sent across an interface.design pattern might also tell you what not to put in the interface.The Memento (316)pattern is a good example.It describes how to encapsulate and save the internal state of an object so that the obiect can be restored to that state later.The pattern stipulates that Memento objects must define two interfaces:a restricted one that lets clients hold and copy mementos,and a privileged one that only the original object can use to sto leve state in the memento Design patterns also specify relationships between interfaces.In particular they often require some classes to have similar interfaces,or they place constraints on the interfaces of some classes.For example,both Decorator (196) and Proxy (233)require the interfaces of Decorator and Proxy objects to be rated and proxied objects.In visitor (366) the visitor must reflect all classes of objects that visitors can visit Specifying object Implementations So far we've said little about how we actually define an object.An object's implementation is defined by its class.The class specifies the object's internal data and representation and defines the operations the object can perform. Our OMT-based notation (su arized in Appendix B)depicts a class as a rectangle with the class name in bold.Operations appear in normal type below the class name.Any data that the class defines comes after the operations.Lines separate the class name from the operations and the operations from the data: 26
Design Patterns: Elements of Reusable Object-Oriented Software 26 that fulfill these requests. The run-time association of a request to an object and one of its operations is known as dynamic binding. Dynamic binding means that issuing a request doesn't commit you to a particular implementation until run-time. Consequently, you can write programs that expect an object with a particular interface, knowing that any object that has the correct interface will accept the request. Moreover, dynamic binding lets you substitute objects that have identical interfaces for each other at run-time. This substitutability is known as polymorphism, and it's a key concept in object-oriented systems. It lets a client object make few assumptions about other objects beyond supporting a particular interface. Polymorphism simplifies the definitions of clients, decouples objects from each other, and lets them vary their relationships to each other at run-time. Design patterns help you define interfaces by identifying their key elements and the kinds of data that get sent across an interface. A design pattern might also tell you what not to put in the interface. The Memento (316) pattern is a good example. It describes how to encapsulate and save the internal state of an object so that the object can be restored to that state later. The pattern stipulates that Memento objects must define two interfaces: a restricted one that lets clients hold and copy mementos, and a privileged one that only the original object can use to store and retrieve state in the memento. Design patterns also specify relationships between interfaces. In particular, they often require some classes to have similar interfaces, or they place constraints on the interfaces of some classes. For example, both Decorator (196) and Proxy (233) require the interfaces of Decorator and Proxy objects to be identical to the decorated and proxied objects. In Visitor (366), the Visitor interface must reflect all classes of objects that visitors can visit. Specifying Object Implementations So far we've said little about how we actually define an object. An object's implementation is defined by its class. The class specifies the object's internal data and representation and defines the operations the object can perform. Our OMT-based notation (summarized in Appendix B) depicts a class as a rectangle with the class name in bold. Operations appear in normal type below the class name. Any data that the class defines comes after the operations. Lines separate the class name from the operations and the operations from the data: