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

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Introduction Structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities. Introduction FacadeDecoratorCompositeAdapterFlyweightProxy 2/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 Introduction Facade DecoratorCompositeAdapterFlyweightProxy 3/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Facade client classes subsystem classes Façade Without Facade With Facade Introduction Facade DecoratorCompositeAdapterFlyweightProxy 4/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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. Introduction Facade DecoratorCompositeAdapterFlyweightProxy 5/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Consequences  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 KEY CONCEPT Facade Design Pattern Introduction Facade DecoratorCompositeAdapterFlyweightProxy 6/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser :Client cMethodOfFacade() singleton :Facade :C myCMethod() (return if any) Sequence Diagram for Façade Introduction Facade DecoratorCompositeAdapterFlyweightProxy 7/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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. Introduction Facade DecoratorCompositeAdapterFlyweightProxy 8/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 IntroductionFacade Decorator CompositeAdapterFlyweightProxy 9/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Applicability  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 KEY CONCEPT Key Concept: Decorator Design Pattern IntroductionFacade Decorator CompositeAdapterFlyweightProxy 10/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Client objDecorated 1 Decoration doAction() Substance doAction() Component add( Component ) doAction() void doAction(){ ….. // do actions special to this decoration objDecorated.doAction(); // pass along } Decorator Class Model (Fig 8.9) IntroductionFacade Decorator CompositeAdapterFlyweightProxy 11/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser :Client doAction() decoration1 :Decoration doAction() Decoration1.objDecorated :Decoration :Substance doAction() Sequence Diagram for Decorator IntroductionFacade Decorator CompositeAdapterFlyweightProxy 12/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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. IntroductionFacade Decorator CompositeAdapterFlyweightProxy 13/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Composite  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. KEY CONCEPT Key Concept: Composite Design Pattern IntroductionFacadeDecorator Composite AdapterFlyweightProxy 14/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser NonLeafNode “every object involved is a Component object” “non-leaf nodes have one or more components” leaf nodenon-leaf node Objects Classes Component 1..n Basis for Composite Class Model IntroductionFacadeDecorator Composite AdapterFlyweightProxy 15/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser etc. NonLeafNode do I t() component Component add( Component ) do I t() LeafNode do I t() TypeANonLeafNode do I t() TypeBNonLeafNode do I t() 1..n Client FOR ALL elements e in component e.do I t() Composite Class Model IntroductionFacadeDecorator Composite AdapterFlyweightProxy 16/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Employee Hierarchy Pete :President Able :Manager Becky :Manager Lonny :Teller Cal :Clerk Tina :Teller Thelma :Teller We need to add and remove employees at runtime and execute operations on all of them. KEY CONCEPT Design Goal : Flexibility, Correctness IntroductionFacadeDecorator Composite AdapterFlyweightProxy 17/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser reports 1..n Setup Employee stateName() Clerk stateName() President stateName() Supervisor add(Employee) Teller stateName() Manager stateName() Client Bank/Teller Example IntroductionFacadeDecorator Composite AdapterFlyweightProxy 18/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Component Container Window ….. component 1..n Canvas Composite in java.awt (Fig 8.24)  Comments on Composite  Decorator is a special case of Composite  Decorator intention is different: add responsibilities at runtime. IntroductionFacadeDecorator Composite AdapterFlyweightProxy 19/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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. KEY CONCEPT Adapter Design Pattern IntroductionFacadeDecoratorComposite Adapter FlyweightProxy 20/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Client AbstractClass clientNameForRequiredMethod() { adaptee. requiredMethod();} adaptee RequiredClass requiredMethod() Adapter clientNameForRequiredMethod() Adapter Example :Client clientNameForRequiredMethod() :AbstractClass :Adapter RequiredMethod() adaptee :RequiredClass IntroductionFacadeDecoratorComposite Adapter FlyweightProxy 21/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Financial amount() Principle computeValue() Client Legacy systemAdaptationApplication We want to separate the application as a whole from financial calculations which will be performed externally. KEY CONCEPT Design Goal : Flexibility and Robustness Adapter Design Pattern (Fig 8.29) FinantialAdapter amount() IntroductionFacadeDecoratorComposite Adapter FlyweightProxy 22/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 Flyweight doAction(Context) ConcreteFlyweight doAction( Context ) FlyweightFactory getFlyweight(Characteristic) Client 1..n (Figure 8.33) IntroductionFacadeDecoratorCompositeAdapter Flyweight Proxy 23/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Comments on Flyweight  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. KEY CONCEPT Flyweight Design Pattern IntroductionFacadeDecoratorCompositeAdapter Flyweight Proxy 24/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 IntroductionFacadeDecoratorCompositeAdapterFlyweight Proxy 25/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Adaptation BaseActiveClass expensiveMethod() anotherMethod() RealActiveClass expensiveMethod() anotherMethod() Client realActiveObject... // One way to check if really needed: if ( realActiveObject == null ) // never referenced { realActiveObject = getRealActiveObject(); realActiveObject.expensiveMethod(); } else // try to avoid calling the real expensiveMethod() Proxy expensiveMethod() anotherMethod() Instantiate with Proxy object Proxy Design Pattern IntroductionFacadeDecoratorCompositeAdapterFlyweight Proxy 26/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser realExpensiveMethod() :Client expensiveMethod() :Proxy:RealActiveClass ( if needed: ) Sequence Diagram for Proxy -- Avoid unnecessary data downloads. -- to call expensive or remote methods. KEY CONCEPT Design Goal : Efficiency and Reuse IntroductionFacadeDecoratorCompositeAdapterFlyweight Proxy 27/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser TelNums value: Vector getTelNums(): Vector showMiddleRecord() RemoteTelNums getTelNums() TelephoneApp display( TelNums ) display MiddleRecord() remoteTelNums... // One way to check if really needed: if ( value == null ) // never referenced remoteTelNums.getTelNums(); else // no need to call ‘getTelNums()’ TelNumsProxy getTelNums() static 1 Setup Ensures that TelephoneApp makes calls with TelNumsProxy instance Proxy Example (Figure 8.44) IntroductionFacadeDecoratorCompositeAdapterFlyweight Proxy 28/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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. IntroductionFacadeDecoratorCompositeAdapterFlyweight Proxy 29/30

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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  Flyweight gains the advantages of using multiple instances while minimizing space penalties  Proxy avoids calling expensive operations unnecessarily IntroductionFacadeDecoratorCompositeAdapterFlyweightProxy 30/30