Design Patterns

1. Design Patterns; Gamma, Helm, Johnson, Vlissides Reference: Design Patterns Contents • Terminology in object-oriented design • Mechanisms for reuse • Designing for change • Categorizing and selecting design patterns

2. Terminology • Object Interface a. Signature of a method • Toolkits • Frameworks • Design Patterns

3. Class diagram Name attributes Object Interface Every method in the class has its own unique signature return_type name (parameter types) The set of all signatures defined by an object’s methods or operations is called the object interface. methods This interface characterizes the complete set of requests that can be sent to the object.

4. ClassA int metod1(int param); void resize( ); ClassB intmetod1(intparam); int metod1(int param); void resize( ); void resize( ); Specifying Object Interfaces Signature of a method: • name • parameters • return type Interface Possible message recipients

5. Circle Shape virtualdouble area( ) ; virtualvoid resize(int scale) ; virtualdouble area( ) = 0; virtualvoid draw( ) ; virtualvoid draw( ) = 0; virtualvoid resize(int scale) = 0; Rectangle virtualdouble area( ) ; virtualvoid draw( ) ; virtualvoid resize(int scale) ; Implementation of an Interface in C++ Interface provided by an abstract class Concrete realizations receive the messages

6. Class Hierarchy Shape Rectangle Circle Square Messages directed to aShapeobject can be received by instances of any of these concrete classes.

7. Toolkits A toolkit is a set of related and reusable classes designed to provide general-purpose functionality. – Gamma et al. Examples: Collection classes: Vector, Stack, Queue, List, etc: Found in libraries such as java.util or the C++ STL The C++ stream library

8. Frameworks A framework is a set of cooperating classes that make up a reusable design for a specific class of software. – Gamma, et al. The framework dictates the architecture of your application. It captures the design decisions that are common to the domain of the application. It establishes the partitioning into classes and objects and the pattern of collaboration between objects. Frameworks promote designreuse Example: the java awt

9. Design Patterns Patterns capture solutions to particular design problems. They provide for the reuse of successful designs. Incorporate design experience. A design pattern is like a template that can be applied in many different situations. A design pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects) solves it. – Gamma et al.

10. Elements of a Design Pattern Pattern Name Names allow the designer to work at a higher level of abstraction. Names make it easier to talk about and think about designs. Description of the problem Describes the problem and its context. The Solution Describes the classes that make up the design, their relationships, and collaborations. The Consequences The results and tradeoffs of applying the pattern.

11. Purpose Design Pattern Aspects that can vary Creational Abstract Factory Families of product objects Builder Creation of a composite object Factory Method Subclass of object instantiated Structural Adapter Interface to an object Facade Interface to a subsystem Flyweight Storage costs of objects Proxy How an object is accessed Behavioral Command When & how a request is fulfilled Iterator Traversal of elements in an aggregate Categories of Design Patterns {Partial listing}

12. Notation B A A B ClassName Implementation pseudocode class method o Symbol Meaning Aggregation Object A instantiates B B is a subclass of A Comment box

13. Command Pattern Intent Encapsulate a request as an object letting you: • Parameterize clients with different requests • Queue or log requests • Support undo operations

14. Command Client execute() Invoker ConcreteCommand Receiver execute() o action() state receiver_action() Command Pattern Structure

15. Command Pattern Participants • Command -- declares an interface for executing an operation • ConcreteCommand -- defines a binding between a Receiver object and an action --implements execute() by invoking the corresponding operation(s) on Receiver • Client (Applicatiojn) -- creates a ConcreteCommand object and sets its receiver • Invoker (Menuitem) --asks the command to carry out the request • Receiver (Document) --knows how to carry out the request. (Any class may serve as Receiver)

16. aReceiver anInvoker aClient aCommand new Command add(aCommand) execute( ) action( ) Command Pattern Collaborations

17. Command Pattern Collaborations • The Client creates a ConcreteCommand object and specifies its receiver. • An Invoker object stores the ConcreteCommand object. • The invoker issues a request by calling execute( ) on the command. When commands are undoable, ConcreteCommand stores state for undoing prior to invoking execute( ). • The ConcreteCommand object invokes operations on its receiver to carry out the request.

18. Command Pattern Consequences • Command decouples the object that invokes the operation from the one that knows how to perform it. • Commands are first-class objects. They can be manipulated and extended like any other object. • Its easy to add new Commands, because you don’t have to change existing classes. • Commands can be assembled into a composite command.

19. Menu MenuItem select( ); App Push Pop Command execute() execute( ) Stack item ask( ) S-> push(item) run( )

20. Further Information about Design Patterns Design Patterns Home Page http://hillside.net/patterns/ Links of particular interest: Doug Lea’s FAQ on Design Patterns Setting up a Design Pattern study group