Design Patterns. On Design Patterns. Becoming a Master Designer. Patterns & Frameworks

Transcription

1 On Design Patterns A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution Good designers know not to solve every problem from first principles They reuse solutions This is very different from code reuse Software practitioners have not done a good job of recording experience in software design for others to use 1 Design Patterns We propose design patterns as a new mechanism for expressing object oriented design experience. Design patterns identify, name and abstract common themes in object oriented design. They capture the intent behind a design by identifying objects, collaborations and distribution of responsibilities Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addison-Wesley, 1995, ISBN Patterns & Frameworks Patterns support reuse of software architecture and design They capture static and dynamic structures of successful solutions to problems. These problems arise when building applications in a particular domain Frameworks support reuse of detailed design and program source text A framework is an integrated set of components that collaborate to provide a reusable architecture for a family of related applications Frameworks t to be less abstract than patterns Together, design patterns and frameworks help to improve key quality factors like reusability, extensibility and modularity 3 Becoming a Master Designer Learn the rules Algorithms and data structures Languages Mathematics Learn the principles Structured and modular programming Theory of software engineering OO design and programming Study the designs of masters Design patterns must be understood, memorized and applied Thousands of existing patterns: are they all memorable? 4 Design Patterns Solve Design Problems Finding appropriate classes Determine class granularity How abstract, how correct Specify interfaces Specify implementation Put reuse to work Inheritance vs. Client-Supplier Relate run time and compile time structures Program text may not reflect design Design Patterns Solve Design Problems 2 Design for change is difficult Common problems Explicit object creation Use name of interface, not name of implementation Depence of particular operations Avoid hard coded operations Depencies on hardware or software platforms Depencies of object representation Depencies on algorithms Tight coupling 5 6

2 Claims of the Pattern Community Well defined design principles have a positive impact on software engineering Achievable reusability Provide common vocabulary for designers Communicate, document, explore alternatives Patterns are like micro architectures Useful for building small parts of a system Reduce the learning time for understanding class libraries Avoid redesign stages by using encapsulated experience 7 When to Use Patterns Solutions to problems that recur with variations No need for pattern if the problem occurs in only one context Can we generalize the problem instance in which we are interested? Solutions that require several steps Not all problems need all steps Patterns can be overkill if solution is a simple linear set of interactions Solutions where the solver is more interested in does there exist a solution? than in a solution s complete derivation Patterns often leave out lots of detail 8 Pattern Drawbacks Patterns do not lead to direct code reuse Patterns are often deceptively simple You may suffer from pattern overload Patterns must be validated by experience and debate rather than automated testing Integrating patterns into a process is human intensive rather than a technical activity General Template Name Intent: what does the pattern do? Motivation: a scenario of pattern applicability Applicability: in which situation can this pattern be applied Participants: describe participating classes/objects Collaborations: how do the participants carry out their responsibilities? Diagram: graphical representation of the pattern Consequences: how does the pattern support its objectives Implementation Examples 9 10 Classification Adapter Pattern Creational Deal with initializing and configuring collections of classes and objects Prototype, Singleton, Abstractor Factor, Builder Structural Deal with decoupling interface and implementation of classes and objects Adaptor, Façade, Decorator Behavioral Deal with dynamic interface and implementation of classes and objects Visitor, Iterator, Master-Slave 11 Intent Convert the interface of a class into another interface what the client expects Let classes work together that couldn t otherwise Motivation Applicability Reuse of classes Class is not reusable because its interface does not match the domain-specific interface If a class with a different, or incompatible, interface is expected, we do not want to change the reusable classes to suit the new application 12

3 Adapter Example EDITOR expects a SHAPE TEXT_VIEW is not a SHAPE TEXT_SHAPE is a SHAPE and TEXT_VIEW Features are mapped (body calls relevant method) to TEXT_VIEW FIGURE_SHAPE SHAPE TEXT_SHAPE EDITOR TEXT_VIEW 13 Adapter Applicability Want to use an existing class but its interface does not match the one you need Want to create a reusable class that cooperates with unrelated or unforeseen classes with incompatible interfaces Object Adapter Only Need to use several existing subclasses, but its impractical to adapt their interfaces by subclassing each one of them Object adapter can adapt the interface of its parent class 14 Adapter Participants, Diagram Object Adapter Diagram TARGET Application specific interface that clients use Client Collaborating classes Adaptee Defines an interfaces that needs adapting Adapter sometimes called a wrapper The wrapper is responsible for the functionality not provided by the adaptee CLIENT TARGET ADAPTEE ADAPTER method calls Collaboration Clients call on Adapter instance, in turn Adapter calls on Adaptee methods TARGET ADAPTER adaptee : ADAPTEE method_for_target CLIENT ADAPTEE method uses adaptee.method Adapter Object Pseudocode class ADAPTER feature instance_adaptee : ADAPTEE method_for_target is instance_adaptee.method class ADAPTEE feature method is 17 Adapter Object Stack Implementation The Adapter pattern where stack operations are calls to equivalent sequence operations Sequence containers Push use the Sequence puthead since container is a Sequence public void push(object obj) { container.puthead(obj); Pop use the Sequence takehead since container is a Sequence public Object pop() { return container.takehead(); 18

4 Adapter Consequences There are tradeoffs a class adapter inheritance Adapt Adaptee to Target by committing to concrete Adapter class a class adapter won t work when we want to adapt a class and all its subclasses Let Adapter override some of Adaptee s behavior Adapter is a subclass of Adaptee Introduces only one object No additional pointer indirection is needed to get adaptee There are tradeoffs an object adapter uses One Adapter can work with many Adaptees Adaptee and all its subclasses Can add functionality to all Adaptees at once Makes it harder to override Adaptee behavior Requires subclassing ADAPTEE and making ADAPTER refer to the subclass rather than the ADAPTEE itself 19 Intent Facade Pattern Provide a common interface to a set of interfaces within a subsystem Defines a higher level interface that should make the subsystem easier to use Motivation Structuring a system into subsystems reduces complexity A common design goal is to minimize communication between subsystems. A facade provides a simplified interface to the more general facilities of subsystems 20 Facade Diagram Clients Facade Subsystem classes 21 Facade Applicability Want to provide simple interface to a collection of complex subsystems Provide a simple default view As systems grow, classes become smaller more refined Better for reuse More difficult for clients to use Decouple subsystems from clients Reduce implementation depencies Layer your subsystems Each layer has a single entry point Layers communicate only through Facade interface 22 Facade Participants, Example Facade Compiler Knows which subsystem classes are responsible for a request Delegates client requests to appropriate subsystem objects Subsystems Scanner, Parser, StatementTypeNode(s), etc. Implement system functionality Handle work assigned by Facade object Have no knowledge of the facade Keep no references to it Facade Collaborations Clients communicate with the subsystem by sing requests to Facade Facade forwards requests to subsystem Facade may have to translate its interface to subsystem interface (use Adapter) Clients that use facade don t have direct access to the subsystems 23 24

5 Benefits Facade Consequences Shields clients from subsystem components Reducing number of objects clients deal with Promotes weak coupling between subsystems and clients Can vary components of subsystem without affecting clients Doesn t prevent expert clients from direct access to subsystems Choice between ease of use and generality Facade Pseudocode class COMPILER feature { NONE nodetree: NODE scanner : SCANNER //Individual subsystems parser : PARSER emitter : EMITTER feature compile is nodetree parser.parse ( scanner ) emitter.output ( nodetree ) Intent Decorator Pattern Attach additional responsibilities to an object dynamically Provide a flexible alternative to subclassing for exting functionality Motivation Applicability Want to add responsibility to individual objects not to entire classes Add properties like border, scrolling, etc to any user interface component as needed Enclose object within a decorator object for flexibility Nest recursively for unlimited customization Decorator Example Compose a border decorator with a scroll decorator for text view a_border_decorator Component a_scroll_decorator Component a_text_view Decorator Example Diagram Decorator Applicability VISUAL_COMPONENT * draw * TEXT_VIEW + DECORATOR * component : COMPONENT draw SCROLL_DECORATOR + BORDER_DECORATOR + draw draw scroll_position border_width draw_border scroll_to Add responsibilities to individual objects dynamically and transparently Without affecting other objects For responsibilities that can be withdrawn When subclass extension in impractical Sometimes a large number of indepent extensions are possible Avoid combinatorial explosion Class definition may be hidden or otherwise unavailable for subclassing 29 30

6 Decorator General Structure CONCRETE COMPONENT + method COMPONENT * method * CONCRETE_DECORATOR_A + method other_feature DECORATOR * component : COMPONENT CONCRETE_DECORATOR_B + method another_feature Component Decorator Participants Defines the interface objects that can have responsibilities added to them dynamically Concrete component Defines an object to which additional responsibilities can be attached Decorator Maintains a reference to a component object and defines an interface that conforms to COMPONENT Concrete decorator Add responsibilities to the component Decorator Consequences Benefits More flexibility than static inheritance Can add and remove responsibilities dynamically Can handle combinatorial explosion of possibilities Avoids feature laden classes high up in the hierarchy Pay as you go when adding responsibilities Can support unforeseen features Decorators are indepent of the classes they decorate Functionality is composed in simple pieces Liabilities From object identity point of view, a decorated component is not identical Decorator acts as a transparent enclosure Cannot rely on object identity when using decorators Lots of little objects Often result in systems composed of many look alike objects Differ in the way they are interconnected, not in class or value of variables Can be difficult to learn and debug 33 Decorator Implementation Component class COMPONENT feature deferred method Concrete component class CONC_COMP feature method is Decorator class DECORATOR feature component : COMPONENT Concrete decorator class CONC_DEC feature method is pre_resp ; component.method ; post_resp 34 Pattern Example Behavioral Based On Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addison-Wesley, ISBN Intent Iterator Pattern Access elements of a container sequentially without exposing the underlying representation Motivation Be able to process all the elements in a container Different iterators can give different sequential ordering Binary tree Preorder, inorder, postorder Do not need to ext container interface 35 36

7 Iterator Example Iterator Example Client BINARY_TREE size insertleft ( NODE, ELEMENT ) remove ( PARENT, NODE ) Iterator knows the internal structure export all relevant features to it TREE_ITERATOR make_inorder make_preorder make_postorder next alldone item tree_items : TREE_ITERATOR from create tree_items.make_inorder ( a_tree ) until tree_items.alldone loop item := tree_items.item process ( item ) tree_items.next loop CONTAINER + size add remove Iterator Pattern ITERATOR * next alldone * item * CONCRETE_ITERATOR + make_1 make_2 next alldone item Iterator Applicability Access a container s contents without knowing about or using its internal representation Support multiple traversals Provide a uniform interface for traversing a container s contents Support polymorphic iteration Container: could provide a method to create an instance of an iterator Iterator: defines the interface for accessing and traversing a container s contents Concrete iterator: Keeps track of the current object in the container Computes the next object in a sequence of the container s objects Iterator Consequences Supports variations in the traversal of a container Complex containers can be traversed in different ways Easy to change traversal order Iterators simplify the container interface Do not need iterator instance in container interface Multiple simultaneous traversals Each iterator keeps track of its own state Can implement null iterators alldone is always TRUE Useful in traversing tree structures At each level ask for iterator for children At leaf level get the null iterator No exceptions at the boundary Inorder Traversal Binary Tree public Enumeration inorderlrtraversal() { return new Enumeration() { declare variables needed by the enumeration { initialization program for the enumerator public boolean hasmoreelements() { provide the definition public Object nextelement() { provide the definition 41 42

8 Inorder Traversal Binary Tree 2 // declare variables needed by the enumeration private Stack btstack = new Stack(); { // initialization program for the enumerator simulate // recursion by programming our own stack; need to // get to the leftmost node as it is first in the enumeration Node node = tree; while (node!= null) { btstack.add(node); node = node.left; public boolean hasmoreelement() { return!btstack.isempty(); Inorder Traversal Binary Tree 3 public Object nextelement() { if (btstack.isempty()) throw new NoSuchElementException(); Node node= (Node) btstack.remove(); Object result = node.datum; // next data to return if (node.right!= null) { // find next sequence node node = node.right; do { btstack.add(node); // get leftmost node in node = node.left; // right sub-tree while (node!= null) return result; Inorder Traversal Binary Tree 4 Visitor Pattern Init after after Stack call 1 call An enumerator is always 1 element ahead of the user root Top of stack initially Top of stack after 2 nd call to nextelement Top of stack after 1 st call to nextelement Intent Represent an operation to be performed on the components of an object structure Define new operations on the structure without changing classes representing the components Consider a compiler using an abstract syntax tree to represent the program VAR_NODE type_check generate_code pretty_print NODE * type_check * generate_code * pretty_print * ASSIGN_NODE type_check generate_code pretty_print Visitor Example BON for SGML Example Consider programs to process SGML tags Motivation Need node classes to be indepent of the operations but still make use of polymorphism Have the notion of the Nodes accepting visitors and directing them to the appropriate operation Have two hierarchies: Node & Operation P_TAG tangle weave display SGML_TAG * tangle * weave * display * Want to add literate programming processors; need to modify all classes recompile everything including deferred classes LI_TAG tangle weave display * VISITOR PS_GENERATE Same structure for each operation * SGML_TAG LI_TAG Same structure for each tag 47 48

9 Visitor Applicability Object structure contains many classes of objects with differing interfaces and wants to perform operations that dep on their concrete classes Many distinct and unrelated operations need to be performed Do not want or are unable to clutter the concrete classes with these operations Keep the related sub-operations (specific to each concrete class) together The classes defining the object structure rarely change, but you often want to define new operations over the structure Changing object structure means redefining the interface to all visitors which is costly 49 Visitor General Structure VISITOR * visit_elem_a(elem_a) * visit_elem_b(elem_b) * CONC_VISITOR_1 + visit_elem_a(elem_a) visit_elem_b(elem_b) accept(vistor) ELEMENT * accept(vistor) * CONC_ELEMENT_A + CONC_VISITOR_2 + CONC_ELEMENT_B + 50 Visitor -- Participants Element Defines an accept method for Visitors Concrete element Implements the accept method for Visitors Visitor Declares visit operation for each CONC_ELEM class Visitor accesses the element from its particular interface Concrete visitor Implements each operation declared by Visitor Each operation implements a fragment of the algorithm defined for the concrete visitor Provides the context for the algorithm State accumulates throughout processing Implements the high level organization Enumerating the elements Processing each turn 51 Visitor Collaboration Concrete visitor loops over the elements Visitor ss accept to the element telling them which visitor Element ss visit_element back to visitor Selects which method in the visitor to execute CONC_VISITOR 2 1 accept (CONC_VISITOR) 2 visit_li_tag(conc_element) 1 CONC_ELEMENT 52 Visitor TAG Implementation Visitor Concrete Visitor Implementation deferred class SGML_TAG feature accept (VISITOR visitor) is deferred --other features class LI_TAG inherit SGML_TAG feature accept (VISITOR visitor) is do visitor.visit_li_tag( Current ) deferred class VISITOR feature -- have one visit routine for each command visit_li_tag (LI_TAG tag) is deferred visit_p_tag (P_TAG tag) is deferred visit_ul_tag(ul_tag tag) is deferred 53 class CONC_VISITOR inherit VISITOR feature get_elements -- attaches elements to the iterator while not elements.alldone do elements.item.accept( Current ) elements.forth visit_li_tag(li_tag tag) is do visit_ul_tag(ul_tag tag) is do visit_p_tag(p_tag tag) is do 54

10 Visitor Consequences Adding new operations is easy New operation implements visitor interface for the components All the fragments of the visitor algorithm are in one file related behaviors are all in one file Unrelated operations and fragments are in other visitor classes Contrast with having to change each of the component classes to have the operation fragment Each class has a fragment of each of the operations Adding new concrete elements is difficult Need to modify visitor class Need to modify each concrete visitor Can sometimes simplify as many elements have common behavior (default behavior) Create subclasses of level 1 for more specific behavior for the new elements For many structures, components do not change rapidly so this is not a problem 55 build general internal ADT Example Multi-Level Visitor PARSER + PARSER_ TAGNLE ext ADT for program references SGML_VISITOR * EMITTER_ TANGLE output program text for compiler echo input from internal ADT EMITTER + EMITTER_ PS output in postscript 56 Singleton Pattern Pattern Example Creational Based On Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addison-Wesley, ISBN Intent Ensure a class has only one instance Provide a global point of access Motivation Some classes must only have one instance file system, window manager Applicability Must have only one instance of a class Must be accessible from a known location Singleton - Abstract Architecture Specific to Eiffel has once function but not static variables Singleton Participants Singleton Used to type a class as a singleton Single instance class The class that should have only one instance Singleton accessor Declares access point for a single instance Instance accessor Access point (storage location) for the single instance Client Uses instance accessor to get the single instance 59 60

11 Singleton Scenario Singleton Class class SINGLETON feature {NONE frozen the_singleton : SINGLETON is -- The unique instance of this class once Result := Current invariant Enforces single instance property only_one_instance: Current = the_singleton Singleton Accessor Class deferred class SINGLETON_ACCESSOR feature {NONE singleton : SINGLETON is deferred -- Access to a unique instance. -- Must be redefined as once function. is_real_singleton : BOOLEAN is do Result := singleton = singleton Enforces single invariant instance property singleton_is_real_singleton: is_real_singleton 63 Instance Accessor Class class INSTANCE_ACCESSOR inherit SINGLETON_ACCESSOR rename singleton as the_instance feature the_instance: SINGLE_INSTANCE_CLASS is -- Create the only instance in the system once create Result.make() 64 Singleton Consequences Sole instance is extensible by subclassing Clients use exted instance without modification dynamically Reduce name space Avoids adding global variables storing single instance Singleton Problem As defined only one SINGLETON is permitted in the system. The once feature in SINGLETON is common to all instances The solution is to have a once feature for each needed singleton The invariant remains in the SINGLETON class 65 66

12 Singleton Solution 1 SINGLETON class Make the Singleton class deferred Make the_singleton deferred Keep the invariant INSTANCE class Inherit from SINGLETON Make the_singleton effective 67 Singleton Solution 1 deferred class SINGLETON feature {NONE the_singleton : SINGLETON is deferred -- The unique instance of this class -- Should be redefined as a once function -- returning Current in concrete subclasses invariant only_one_instance: Current = the_singleton Enforces single instance property 68 Single Instance Class Solution 1 class INSTANCE inherit SINGLETON creation {INSTANCE_ACCESSOR make feature the_singleton: INSTANCE is once Result := Current Restricts access Catch at compile time 69 Singleton Solution 2 SINGLETON class as for solution 1 Make the Singleton class deferred Make the_singleton deferred Keep the invariant INSTANCE_SINGLETON Inherit from SINGLETON Make the_singleton effective INSTANCE class Inherit from INSTANCE_SINGLETON, instead of SINGLETON 70 Solution 2 Abstract Architecture 71 Solution 1 & 2 Tradeoffs Solution 1 Requires an an additional change to the instance class that changes its interface Does not introduce any new classes Can have compiler catch invalid create attempts Solution 2 Introduces a new class Minimizes the change to the instance class does not change the interface Invalid attempts can only be caught at run time 72

13 Singleton Example: League Singleton Example: League 2 /cs/dept/course/ /w/3311/pattern-examples/singleton.tar Class CAPTAIN is a SINGLETON As a result, all TEAMs created will refer to the same CAPTAIN object. To contrast this setup with one that does not use an accessor class, modify the provided ACE file so that the root class is BROKEN_LEAGUE. You will get a compile-time error as soon as you try to make Ringo a captain :) PLAYER PLAYER * SINGLETON + CAPTAIN LEAGUE * SINGLETON_ ACCESSOR + CAPTAIN_ ACCESSOR Singleton Related Patterns Abstract Factory, Builder and Prototype can use Singleton Intent Abstract Factory Provide an interface for creating families of related or depent objects without specifying their concrete classes Motivation Building a user interface toolkit that supports multiple look and feel standards Motif, Presentation Manager, X Window Have different appearances and behavior for a large set of sub-classes Scroll bars, windows, buttons, WIDGET_FACTORY + create_scrollbar + create_window + MOTIF_WIDGET FACTORY + create_scrollbar create_window AF Example MOTIF_WINDOW CLIENT PM_WIDGET FACTORY + create_scrollbar create_window WINDOW + MOTIF_ SCROLLBAR PM_WINDOW SCROLLBAR+ PM_ SCROLLBAR 77 AF Applicability & Participants Applicability System should be indepent of how its products are created, composed and represented System should be configured with one of multiple families of products Family of related product objects is designed to be used together and you need to enforce this constraint Provide a class library of products and you want to reveal just their interfaces not their implementations Participants Abstract factory Declares an interface for operations that create abstract product objects Concrete factory Implements the operations to create product objects 78

14 Participants Abstract product AF Participants Declares an interface for a type of product object Concrete product Defines a product object to be created by the corresponding concrete factory Implements Abstract_Product interface Client Uses only the interfaces declared by Abstract_Factory and Abstract_Product Collaboration Normally a single instance of Concrete_Factory is created at run time Creates product objects having a particular implementation To create different product objects, use a different concrete factory Abstract_Factory defers creation of product objects to its Concrete_Factory sub-classes 79 AF Consequences It isolates concrete classes Factory encapsulates the responsibility and process of creating product objects Isolates clients from implementation classes It makes exchanging product families easy Concrete factory appears once where it is instantiated Promotes consistency among products Supporting new kinds of products is difficult Fixes set of products to be created 80 AF Implementation AF Implementation 2 class MAZE_FACTORY feature make_make : MAZE is local maze : MAZE do create maze; Result := maze make_room (id : INTEGER) : ROOM is local r : ROOM do create room.make(id); Result := room make_door ( r1 : ROOM; r2 :ROOM) : DOOR is local door : DOOR do create door.make(r1, r2); Result := door make_wall : WALL is local wall : WALL do create wall; Result := wall Client program class MAZE_GAME creation create_maze feature create_maze (factory : MAZE_FACTORY ) is local maze : MAZE; r1, r2 : ROOM; door : DOOR do maze := factory.make_maze; r1 := factory.make_room(1) r2 := factory.make_room(2); door := factory.make_door(r1, r2) maze.add_room (r1); maze.add_room(r2) r1.set_side (North, factory.make_wall); r1.set_side (East, door) r1.set_side (South, factory.make_wall) r1.set_side (WEST, factory.make_wall) r2.set_side (North, factory.make_wall) r2.set_side (East, factory.make_wall) r2.set_side (South, factory.make_wall); r2.set_side (West, door) 82 AF Implementation 3 class ENCHANTED_MAZE_FACTORY inherits MAZE_FACTORY feature make_room (id : INTEGER ) : ROOM is local room : ENCHANTED_ROOM do create room.make( id ); Result := room make_door (r1 : ROOM; r2 : ROOM ) : DOOR is local door : DOOR_NEEDING_SPELL do create door.make( r1, r2 ); Result := door AF Implementation 4 -- create various games Game : MAZE_GAME Factory_1 : ENCHANTED_MAZE_FACTORY Create factory_1 Create game.create_maze( factory_1 ) Prototype Pattern: Intent specify the kinds of objects to create using a prototypical instance and create new objects by copying this prototype 83 84

15 Prototype Motivation Prototype Motivation 2 Build an editor for musical scores by customizing a general framework for graphical editors Add new objects for notes, rests, staves Have a palette of tools Click on 8 th note tool and add it to the document Assume framework provides Abstract_Graphic class Abstract_Tool subclass for defining tools Graphic_Tool subclass for creating instances of graphical objects and adding them to the document 85 But Graphic_Tool doesn t know how to create instances of music classes Could subclass Graphic_Tool for each kind of music object But have lots of classes with insignificant variations Object composition is a flexible alternative to sub-classing How can we use it in this application Solution is to copy or clone in an instance called a prototype Graphic_Tool is parameterized by the prototype to clone 86 Prototype Example Prototype Structure ROTATE_ TOOL + manipulate GRAPHIC_ TOOL + manipulate GRAPHIC * draw * clone * CLIENT + operation PROTOTYPE* Clone * TOOL * STAFF + draw clone NOTE + manipulate* WHOLE + draw clone HALF + draw clone CONCRETE_1+ clone CONCRETE_2 + clone Prototype Applicability Use when a system should be indepent of how its products are Created, composed and represented When classes to instantiate are specified at run time: dynamic loading To avoid building a class hierarchy of factories that parallels the class hierarchy of products When instances of a class can have one of a few different combinations of state More convenient to install corresponding number of prototypes and clone them 89 Prototype Participants Collaboration Prototype Declares an interface for cloning itself Concrete prototype Implements an operation for cloning itself Client Creates a new object by asking a prototype to clone itself Collaboration Client Asks a prototype to clone itself 90

16 Prototype Consequences Many of the same consequences as Builder and Abstract Factory Hides concrete product classes from the client Reduces number of names client needs to know Can work with application specific classes without modification Additional benefits Adding & removing products at run time Register a prototype instance with client Specifying new objects by varying values define new behavior through object composition Specify objects variables with new values not new classes Effectively define new kinds of objects Client exhibits new behavior by delegating responsibility to the prototype 91 Prototype Consequences 2 Specifying new objects by varying structure Build objects as parts and sub-objects User defines new groupings that can be reused Reduced sub-classing Factory Method produces hierarchy of creator classes that parallels product classes Cloning avoids parallel hierarchy Biggest benefit in languages like C++ that do not treat classes as first class citizens (not real objects themselves); less benefit in SmallTalk as classes are their own prototype Configuring an application with classes dynamically C++ lets you load classes dynamically Liability Each subclass of Prototype must implement clone which can be difficult with circular references 92 Prototype Implementation Prototype Implementation 2 class MAZE_PROTOTYPE_FACTORY creation make feature -- client uses the prototype assuming subclasses are implemented prototype_maze : MAZE; prototype_room : ROOM game : MAZE_GAME; simple_factory : MAZE_PROTOTYPE_FACTORY prototype_door : DOOR; prototype_wall : WALL m : MAZE; d : DOOR; w : WALL; r : ROOM -- Note parameterization with prototypes make ( m : MAZE; r : ROOM; d : DOOR; w : WALL ) is do create m.make; create d.make; create w.make; create r.make prototype_maze := m; prototype_door := d create simple_factory.make(m, r, d, w) prototype_room := r; prototype_wall := w -- create_maze expects a prototype instead of abstract factory create game.create_maze (simple_factory) make_wall : WALL is do Result := prototype_wall.clone make_door(r1: ROOM; r2 : ROOM) : DOOR is do -- to get different types of mazes create with different prototypes Result := prototype_door.clone; Result.set_room(r1, r2) m : ENCHANTED_MAZE; d : DOOR_NEEDING_SPELL; w : WALL; r : ROOM make_room( id: INTEGER) : ROOM is do Result := prototype_room.clone; Result.set_id( id ) create m.make; create d.make; create w.make; create r.make create simple_factory.make( m, r, d, w) make_maze : MAZE is do Result := prototype_maze.clone create game.create_maze( simple_factory ) 93 94