Lecture 14 Structural Design Patterns

1. SWE 316: Software Design and Architecture Lecture 14Structural Design Patterns Ch 8 • To learn the structural design patterns and when to use them. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

2. 2/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Introduction Structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities.

3. 3/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Façade Design Pattern • Design Purpose • Provide an interface to a package of classes • Design Pattern Summary • Define a singleton which is the sole means for obtaining functionality from the package. • Notes: the classes need not be organized as a package; more than one class may be used for the façade. 8.2

4. 4/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Façade With Facade Without Facade client classes Facade subsystem classes

5. 5/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Applicability • To provide simple interface to a complex subsystem, which is useful for most clients. • To reduce the dependencies between the client and the subsystem, or dependencies between various subsystems. • To simplify the dependencies between the layers of a subsystem by making them communicate solely through their facades.

6. 6/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Consequences KEY CONCEPT Facade Design Pattern • It shields the clients from subsystem components, thereby making the subsystem easier to use. • It promotes weak coupling between subsystem and its clients. • Components in a subsystems can change without affecting the clients. • Porting of subsystems is easier. -- modularizes designs by hiding complexity

7. 7/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Sequence Diagram for Façade :Client singleton :Facade :C cMethodOfFacade() myCMethod() (return if any) (return if any)

8. 8/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Implementation • Some classes / objects behind the Facade may be ones that never should be visible to the client, but are necessary for the operations to take place. • The Facade can completely hide these by making them private inner classes to the Facade class. • Comments on Façade • Web services provide functionality at a web site for the benefit of external software. This is the Façade concept. • Servlets are a common Java way of providing server-side Façade functionality.

9. 9/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Decorator Design Pattern • Design Purpose • Add responsibilities to an object at runtime. • Design Pattern Summary • Provide for a linked list of objects, each encapsulating responsibility. 8.3

10. 10/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Applicability KEY CONCEPT Key Concept: Decorator Design Pattern • To add responsibility to individual objects dynamically and transparently, that is, without affecting other objects. • For responsibility that can be withdrawn. -- allows addition to and removal from objects at runtime

11. 11/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Decorator Class Model (Fig 8.9) Component add( Component ) doAction() 1 Client Substance doAction() objDecorated Decoration doAction() void doAction(){ ….. // do actions special to this decoration objDecorated.doAction(); // pass along }

12. 12/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Sequence Diagram for Decorator :Client decoration1 :Decoration Decoration1.objDecorated :Decoration :Substance doAction() doAction() doAction()

13. 13/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Comments on Decorator • Replace the Component interface with an abstract class (if it contains useful base functionality) • Decorator can be thought of as an object version of linked list. • Why use Decorator when a simple Vector or component object seems to suffice? • This will make the code less flexible • The client will have to know about the subclasses • If the subclasses are replaced then the client code would have to change.

14. 14/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Composite KEY CONCEPT Key Concept: Composite Design Pattern • Design Purpose • Represent a Tree of Objects • Design Pattern Summary • Use a Recursive Form in which the tree class aggregates and inherits from the base class for the objects. • Applicability • Allows the creation of a new object from existing objects. • The client will see the new composite object as equivalent to the other objects. -- used to represent trees of objects. 8.4

15. 15/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Basis for Composite Class Model Objects non-leaf node leaf node Component 1..n Classes “non-leaf nodes have one or more components” “every object involved is a Component object” NonLeafNode

16. 16/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Composite Class Model Component add( Component ) doIt() 1..n Client FOR ALL elements e in component e.doIt() LeafNode doIt() NonLeafNode doIt() component etc. TypeANonLeafNode doIt() TypeBNonLeafNode doIt()

17. 17/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Employee Hierarchy KEY CONCEPT Design Goal : Flexibility, Correctness Pete :President We need to add and remove employees at runtime and execute operations on all of them. Able :Manager Becky :Manager Tina :Teller Lonny :Teller Cal :Clerk Thelma :Teller

18. 18/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Bank/Teller Example Employee stateName() Client 1..n reports Supervisor add(Employee) Clerk stateName() Teller stateName() Setup Manager stateName() President stateName()

19. 19/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Composite in java.awt (Fig 8.24) Component 1..n Container component … . . Window Canvas • Comments on Composite • Decorator is a special case of Composite • Decorator intention is different: add responsibilities at runtime.

20. 20/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Adapter Design Pattern KEY CONCEPT Adapter Design Pattern • Design Purpose • Allow an application to use external functionality in a retargetable manner. • Design Pattern Summary • Write the application against an abstract version of the external class; introduce a subclass that aggregates the external class. -- to interface flexibly with external functionality. 8.5

21. 21/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Adapter Example AbstractClass clientNameForRequiredMethod() RequiredClass requiredMethod() :Client :AbstractClass :Adapter adaptee :RequiredClass adaptee Client clientNameForRequiredMethod() RequiredMethod() Adapter clientNameForRequiredMethod() { adaptee. requiredMethod();}

22. 22/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Adapter Design Pattern (Fig 8.29) KEY CONCEPT Design Goal : Flexibility and Robustness Application Adaptation Legacy system We want to separate the application as a whole from financial calculations which will be performed externally. Financial amount() Principle computeValue() FinantialAdapter amount() Client

23. 23/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Flyweight Design Pattern • Design Purpose • Manage a large number of objects without constructing them all. • Design Pattern Summary • Share representatives for the objects; use context to obtain the effect of multiple instances. 8.6 Client Flyweight doAction(Context) Flyweight 1..n FlyweightFactory getFlyweight(Characteristic) ConcreteFlyweight doAction(Context) (Figure 8.33)

24. 24/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Comments on Flyweight KEY CONCEPT Flyweight Design Pattern • Flyweight is to some extent a retreat from full object-orientation: by not treating every instance as a truly separate object, we can bring “less” object-oriented, and we do thus lose some benefits. -- to obtain the benefits of a large set of individual objects without efficiency penalties.

25. 25/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Proxy Design Pattern • Design Purpose • Avoid the unnecessary execution of expensive functionality in a manner transparent to clients. • Design Pattern Summary • Interpose a substitute class which accesses the expensive functionality only when required. 8.7

26. 26/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Proxy Design Pattern BaseActiveClass expensiveMethod() anotherMethod() Client Adaptation Instantiate with Proxy object Proxy expensiveMethod() anotherMethod() realActiveObject RealActiveClass expensiveMethod() anotherMethod() . . . // One way to check if really needed: if ( realActiveObject == null ) // never referenced { realActiveObject = getRealActiveObject(); realActiveObject.expensiveMethod(); } else // try to avoid calling the real expensiveMethod()

27. 27/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Sequence Diagram for Proxy KEY CONCEPT Design Goal : Efficiency and Reuse :Client :Proxy :RealActiveClass -- Avoid unnecessary data downloads. -- to call expensive or remote methods. expensiveMethod() ( if needed: ) realExpensiveMethod()

28. 28/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy TelNums value: Vector getTelNums(): Vector showMiddleRecord() Proxy Example (Figure 8.44) Ensures that TelephoneApp makes calls with TelNumsProxyinstance static TelephoneApp display( TelNums ) display MiddleRecord() TelNumsProxy getTelNums() 1 remoteTelNums RemoteTelNums getTelNums() . . . // One way to check if really needed: if ( value == null ) // never referenced remoteTelNums.getTelNums(); else // no need to call ‘getTelNums()’ Setup

29. 29/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Comments on Proxy • Proxy promotes efficiency: • Avoids time-consuming operations when necessary • The penalties we pay can sometimes be too high: • If the proxy forces us to keep very large amount of data in the memory and its use is infrequent. • Proxy promotes: • Correctness: separate design and code that are independent of retrieval/efficiency from parts concerned with this issue. • Reusability: design and code that are independent of retrieval efficiency are most likely to be reusable. • Flexibility: we can replace one module concerned with retrieval with another • Robustness: proxy isolates parts that check for the validity of retrieved data.

30. 30/30 Introduction Facade Decorator Composite Adapter Flyweight Proxy Summary of Structural Patterns • Structural Design Patterns relate objects (as trees, lists etc.) • Facade provides an interface to collections of objects • Decorator adds to objects at runtime • Composite represents trees of objects • Adapter simplifies the use of external functionality • Flyweightgains the advantages of using multiple instances while minimizing space penalties • Proxy avoids calling expensive operations unnecessarily