Design Patterns (Facade, Composite)

Transcription

1 CS 247: Software Engineering Principles Design Patterns (Facade, Composite) Reading: Freeman, Robson, Bates, Sierra, Head First Design Patterns, O'Reilly Media, Inc Ch 7 Adapter and Facade patterns Ch 9: Composite and Iterator Patterns Electronic text available from UW Library Web site U Waterloo CS247 (Spring 2015) p.1/20

2 Today's Agenda Design patterns: codified solutions that put design principles into practice, to improve the modularity of our code. OO Basics Favour Composition over Inheritance Facade Separation of Concerns Single Responsibility Principle Observer Encapsulate what is likely to change Dependency Inversion PrincipleModel-View-Controller (MVC) Encapsulate Data Representation Liskov Substitutability PrincipleComposite Abstraction (interfaces, ADTs) Law of Demeter Iterator Reuse (through composition, inheritance) Polymorphism Open Closed Principle OO Principles Strategy Design Patterns Template Method Adaptor U Waterloo CS247 (Spring 2015) p.2/20

3 Facade Pattern Problem: complex interface Client of subsystem interacts with multiple (complex?) classes Solution: create a single, simplified interface (class) Restrict, simplify client's interactions with subsystem's classes client classes FACADE subsystem classes U Waterloo CS247 (Spring 2015) p.3/20

4 Metaphor: Facade Pattern U Waterloo CS247 (Spring 2015) p.4/20

5 Example: Project GUI Controller GamePlay Player Card Deck backend of game GameBoard U Waterloo CS247 (Spring 2015) p.5/20

6 Review: Object Composition A compound object represents a composition of heterogeneous, possibly recursive, component objects Law of Demeter: client code interacts with compound object Book Section Developer 0..1 Team subteam 1 Page U Waterloo CS247 (Spring 2015) p.6/20

7 Composite Design Pattern (Idea) The Composite Pattern takes a different approach: gives the client access to all member types in a compound object via a uniform interface. Client Code TeamMember Developer Team Client Code BookUnit Page Chapter U Waterloo CS247 (Spring 2015) p.7/20

8 Metaphor: Composite Pattern collection of devices, each with its own interface Universal Interface for (recursive) collection of devices U Waterloo CS247 (Spring 2015) p.8/20

9 Composite Pattern Problem: composite object consists of several heterogenous parts Client code is complicated by knowledge of object structure Client must change if data structure changes Solution: create a uniform interface for the object's components Interface advertises all operations that components offer Client deals only with the new uniform interface Uniform interface is the union of the components' servcies Client Code Component Operation add(component) Remove(Component) GetChild(int) part Leaf Operation Composite Operation add(component) Remove(Component) GetChild(int) U Waterloo CS247 (Spring 2015) p.9/20

10 Example 0..1 Developer Project Team subteam TeamMember name : string salary() : int print() add(teammember) getmember(int) member Developer salary: int salary() print() ProjectTeam print() add(teammember) getmember(int) U Waterloo CS247 (Spring 2015) p.10/20

11 Team Example Heroes Fantastic Four Avengers SHIELD Human Torch The Thing... Hulk Thor Nick Fury Skrulls Iron Man Ethan Edwards Jazinda Avengers Hulk Hulk Thor Iron Man U Waterloo CS247 (Spring 2015) p.11/20

12 class TeamMember { public: virtual ~TeamMember() {} Uniform Interface // leaf-only operations virtual int salary() const { return 0;} // component-only operations virtual void add(teammember) { } virtual TeamMember getmember(int) const { return NULL;} // shared operations virtual void print() const { std::cout << name_; } protected: TeamMember( const std::string& name ); private: std::string name_; }; U Waterloo CS247 (Spring 2015) p.12/20

13 The leaf classes override the behaviour of leaf-object operations. class Developer : public TeamMember { public: Developer( const std::string&, int); // redefine leaf-only operations virtual int salary() const { return salary_; } // inherit component-only operations // redefine shared operations virtual void print() const; private: int salary_; }; Leaf Class U Waterloo CS247 (Spring 2015) p.13/20

14 Concrete Composite Class class Team : public TeamMember { public: Team ( const std::string& ); virtual ~Team(); // inherit leaf-only operations // redefine component-only operations virtual void add(teammember); virtual TeamMember getmember(int) const; // redefine shared operations virtual void print() const; private: vector<teammember> members_; }; TeamMember Team::getMember(int i) const { return members_.at(i); } U Waterloo CS247 (Spring 2015) p.14/20

15 Uniformity vs. Safety Whether to include component-specific operations in the component interface involves a trade-off between uniformity - preserving the illusion that component objects can be treated the same way - promoted by the Composite Pattern safety - avoiding cases where the client attempts to do something meaningless, like adding components to Leaf objects - promoted by Liskov Substitutability Principle U Waterloo CS247 (Spring 2015) p.15/20

16 Another Example: Expressions 2 Expression value() name() print() left() : Expr right() : Expr Expressions: a+b ab+c-d a BinaryExpr left() : Expr right() : Expr print() Variable name value name() value() print() Plus Minus Multiply Divide U Waterloo CS247 (Spring 2015) p.16/20

17 Composite Pattern TeamMember name : string salary() : int print() add(teammember) getmember(int) member Developer salary: int salary() print() ProjectTeam print() add(teammember) getmember(int) Consequences: + Client deals only with the new uniform interface + New leafs and composite types are easy to add New operations are harder to add (Visitor Pattern) How can client code iterate through a composite object without knowing the composite's structure? U Waterloo CS247 (Spring 2015) p.17/20

18 Recap: Composite Pattern Problem: composite object consists of several heterogenous parts Client code is complicated by knowledge of object structure Client must change if data structure changes Solution: create a uniform interface for the object's components Interface advertises all operations that components offer Client deals only with the new uniform interface Uniform interface is the union of the components' servcies Client Code Component Operation add(component) Remove(Component) GetChild(int) part Operation Leaf Composite Operation add(component) Remove(Component) GetChild(int) U Waterloo CS247 (Spring 2015) p.18/20

19 When Should I Use the Composite Pattern? What's the story? First you tell us Single Responsibility and Substitutability, and now you are giving us a pattern where one class manages the operations of two completely different subclasses. When client mostly treats the structure uniformly client usually ignores differences in element types mostly transverses entire composition there exist reasonable default implementations of operations Alternative is to keep element types distinct all calls to inappropriate operations are caught skeptic U Waterloo CS247 (Spring 2015) p.19/20

20 Summary The goal of design patterns is to encapsulate change Facade Pattern: encapsulates a collection of (complex?) classes Composite Pattern: encapsulates the structure of a heterogeneous, possibly recursive data structure U Waterloo CS247 (Spring 2015) p.20/20