1. 1 Advanced Object-oriented Design – Principles and Patterns Structural Design Patterns

2. 2 Summarizing the Design Themes Think differently about Types Vs. Classes Program to an interface (Type), not an implementation (Class). Favor object composition over class inheritance, black box over white box reuse. Design relationships between objects and their types to achieve good run-time structure. Don’t limit yourself to compile time structures.

3. 3 Structural Design Patterns n Concerned with how classes and objects are composed to form larger structures n Structural class patterns use inheritance to compose interfaces or implementations n Structural object patterns describe ways to compose objects to realize new functionality

4. 4 Topic 1: Adapter Pattern Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

5. 5 Adapter: Applicability n you want to use an existing class, and its interface does not match the one you need. n you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces. n you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one.

6. 6 Adapter: Example

7. 7 Adapter: Model

8. 8 Adapter: Collaborations n Target (PrintInterface) defines the domain- specific interface that Client uses. n Client (Application) collaborates with objects conforming to the Target interface. n Adaptee (HPPrintDriver) defines an existing interface that needs adapting. n Adapter (HPPrintInterface) adapts the interface of Adaptee to the Target interface.

9. 9 Adapter: Consequences n Variation: Instead of delegating to an Adaptee, can an Adapter inherit from an Adaptee ? What are the consequences ? n The amount of work Adapter does depends on how similar the Target interface is to Adaptee's; Varies from simple interface conversion to providing complex operations

10. 10 Adapter: Exercise n As part of you enterprise application you are required to make use of a messaging middleware such as MQSeries. Your application wants to send and rececive messages to other subsystems (such as billing system, and decision support system). However, depending on the installation you want to support multiple message oriented middleware products in the near future (such as DECMessageQ, MS MQ etc.). Could the Adapter pattern provide you a solution ?

11. 11 Topic 2: Proxy Pattern Provide a surrogate or placeholder for another object to control access to it.

12. 12 Proxy: Applicability n A remote proxy provides a local representative for an object in a different address space. n A virtual proxy creates expensive objects on demand. n A protection proxy controls access to the original object.

13. 13 Proxy: Example

14. 14 Proxy: Model

15. 15 Proxy: Collaborations n Proxy (BusinessObjectProxy) »maintains a reference that lets the proxy access the real subject. Proxy may refer to a Subject if the RealSubject and Subject interfaces are the same. »provides an interface identical to Subject's so that a proxy can by substituted for the real subject. »controls access to the real subject and may be responsible for creating and deleting it. »remote proxies are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space; protection proxies check that the caller has the access permissions required to perform a request. n Subject (BusinessObjectInterface) defines the common interface for RealSubject and Proxy so that a Proxy can be used anywhere a RealSubject is expected. n RealSubject (BusinessObjectImpl) defines the real object that the proxy represents.

16. 16 Proxy: Consequences n A remote proxy can hide the fact that an object resides in a different address space. n A virtual proxy can perform optimizations such as creating an object on demand. n Both protection proxies allow for additional housekeeping tasks (such as security verification) when an object is accessed.

17. 17 Proxy: Exercise n The logical subscription data object representing the logical record in memory aggregates multiple physical data records such as payment records, subscription details, credit status etc. The application retrieves a set of logical subscription objects while processing renewals, but has the need to examine the detailed records only on certain subscriptions. For performance reasons, uou would like to avoid loading the subscription data that may not be used. Hence you decide to implement a load on demand scheme where by the actual subscription data is loaded as and when needed by the application. Employ proxy pattern.

18. 18 Topic 3: Facade Pattern Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

19. 19 Facade: Applicability n Hiding complexity: To provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade. n Reducing dependency: there are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability. n Define entry points and layer subsystems: Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.

20. 20 Facade: Example

21. 21 Facade: Model

22. 22 Facade: Collaborations n Facade (Compiler) –knows which subsystem classes are responsible for a request. –delegates client requests to appropriate subsystem objects. n Subsystem classes (Scanner, Parser, ProgramNode, etc.) –implement subsystem functionality. –handle work assigned by the Facade object. –have no knowledge of the facade; that is, they keep no references to it.

23. 23 Facade: Consequences n shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use. n promotes weak coupling between the subsystem and its clients. Often the components in a subsystem are strongly coupled. Weak coupling lets you vary the components of the subsystem without affecting its clients. n help layer a system and the dependencies between objects; eliminates complex or circular dependencies. n Reducing compilation dependencies is vital in large software systems. n It doesn't prevent applications from using subsystem classes if they need to.

24. 24 Facade: Exercise n You are to design a subsystem that takes in subscriptions over the Internet. Behind the scene there is a lot involved in taking in a subscription. For example, you need to figure if this is a new subscription or a renewal. You need to locate the customer data if the subscription is from a repeat customer. You need to verify the credit status of the customer and the payment details of the subscription before accepting it. Based on the customer profile you may want to promote cross selling by suggesting additional products the subscriber may be interested in. Additionally you need to update a Decision Support system with the new subscription on successful creation. Discuss how the Façade pattern may be useful.

25. 25 Topic 4: Decorator Pattern Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extending functionality.

26. 26 Decorator: Applicability n You want to add responsibilities to individual objects dynamically, not to an entire class n Modeling for responsibilities that can be withdrawn. n You want clients to be able to ignore the difference between objects and decorated object instances. n recursively allows an open-ended number of additional responsibilities

27. 27 Decorator : Example

28. 28 Decorator : Collaborations n Component (VisualComponent) –defines the interface for objects that can have responsibilities added to them dynamically. n Concrete Component (Text View) –defines an object to which additional responsibilities can be attached. n Decorator (Decorator) –maintains a reference to a Component object –defines an interface that conforms to Component's interface.. n ConcreteDecorator (BorderDecorator) –adds responsibilities to the component.

29. 29 Decorator : Consequences n More flexibility than static inheritance: responsibilities can be added and removed at run-time simply by attaching and detaching them. In contrast, inheritance requires creating a new class for each additional responsibility (BorderedTextView) n Pay-as-you-go approach: Instead of trying to support all foreseeable features in a complex, customizable class, you can define a simple class and add functionality incrementally with Decorator objects. Functionality can be composed from simple pieces. As a result, an application needn't pay for features it doesn't use n A decorator and its component aren't identical n Lots of little objects: results in systems composed of lots of little objects that all look alike

30. 30 Decorator : Exercise n As part of your on-line subscription site you decide to support logging functionality. That is, you want an log entry to be generated every time a PublishedData object is opened in a Write mode and the content of the data object modified. The logging functionality is not needed when the Published data is accessed in a read only mode.

31. 31 Topic 5: Composite Pattern Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

32. 32 Composite: Applicability n you want to represent part-whole hierarchies of objects. n you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.

33. 33 Composite: Example

34. 34 Composite: Model

35. 35 Composite: Collaborations n Component (Graphic) –declares the interface for objects in the composition. –implements default behavior for the interface common to all classes, as appropriate. –declares an interface for accessing and managing its child components. –(optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate. n Leaf (Line, Text, etc.) –represents leaf objects in the composition. A leaf has no children. –defines behavior for primitive objects in the composition. n Composite (Picture) –defines behavior for components having children. –stores child components. –implements child-related operations in the Component interface. n Client (GraphicEditor) manipulates objects in the composition through the Component interface.

36. 36 Composite: Consequences n defines class hierarchies consisting of primitive objects and composite objects. Primitive objects can be composed into more complex objects, which in turn can be composed, and so on recursively. Wherever client code expects a primitive object, it can also take a composite object. n makes the client simple. Clients can treat composite structures and individual objects uniformly. Clients normally don't know (and shouldn't care) whether they're dealing with a leaf or a composite component. This simplifies client code, because it avoids having to write tag-and-case-statement-style functions over the classes that define the composition. n makes it easier to add new kinds of components. Newly defined Composite or Leaf subclasses work automatically with existing structures and client code. Clients don't have to be changed for new Component classes. n can make your design overly general; makes it harder to restrict the components of a composite.

37. 37 Composite: Exercise n As part of your on-line subscription site you decide to promote certain products. These products may be simple products or products that are packages of other products which in turn may be packages of other products and so on. The customer may decide to buy products separately or as part of a package deal where they buy a set of related products packaged together. You need to write a pricing module which can price products individually or in packages. Could composite pattern be used ? Would your pricing module benefit ?

38. 38 Resources: Principles and Patterns n Designing Object-Oriented C++ Applications using the Booch Method By Robert C. Martin (1994) n Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch n http://www.cetus-links.org/oo_patterns.html http://www.cetus-links.org/oo_patterns.html n http://hillside.net/patterns/patterns.html http://hillside.net/patterns/patterns.html n http://theserverside.com/home/index.jsp http://theserverside.com/home/index.jsp n http://www.cs.wustl.edu/~schmidt/patterns.html http://www.cs.wustl.edu/~schmidt/patterns.html