Structural Design Patterns, 1 1 COMP2110/2510 Software Design Software Design for SE September 17, 2008 2 3 Department of Computer Science The Australian National University 4 18.1 18.2 GoF Structural Design Patterns Structural Family of GoF Structural patterns are concerned with how classes and objects are composed to form larger structures. There are class structural pattersn and objects structural pattern. ADAPTER BRIDGE COMPOSITE DECORATOR FAÇADE FLYWEIGHT PROXY Structural class patterns use inheritance to compose interfaces or implementations (eg, multiple inheritance combining two or more classes into a single class with the properties of all its parents). Example: CLASS ADAPTER. Structural object patterns describe ways to compose objects to realize new functionality. The added flexibility of object composition comes from the ability to change the composition at run-time, which is impossible with static class composition. Example: COMPOSITE, OBJECT ADAPTER. 18.3 18.4
Intent: Convert the interface of a class into another interface clients expect. lets classes work together that couldn t otherwise because of incompatible interfaces. Also known as: WRAPPER Often an API or a toolkit class is not re-uasable simply because its interface doesn t match the specific interface an application requires. Use the pattern if: you want to use an existing class, and its interface does not match the one you need example Consider for example a drawing editor that lets users draw and arrange graphical elements (lines, polygons, text, etc.) into pictures and diagrams. The drawing editor s key abstraction is the graphical object, which has an editable shape and can draw itself. The interface for graphical objects is defined by an abstract class called Shape. The editor defines a subclass of Shape for each kind of graphical object: a LineShape class for lines, a PolygonShape class for polygons... But a TextShape subclass that can display and edit text is considerably more difficult to implement, since even basic text editing involves complicated screen update and buffer management. you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don t necessarily have compatible interfaces An existing UI toolkit already provides a sophisticated TextView class for displaying and editing text. Ideally we would like to reuse TextView to implement TextShape, but the toolkit wasn t designed for Shape classes. So we can t use TextView and Shape objects together. Instead, we could define TextShape so that it adapts the TextView interface to Shape s. We can do this in one of two ways: (1) by inheriting Shape s interface and TextView s implementation or (2) by composing a TextView instance within a TextShape and implementing TextShape in terms of TextView s interface. These two approaches correspond to the class and object versions of the ADAPTER pattern. We call TextShape an adapter. 18.5 18.6 uses object composition: uses multiple inheritance to adapt one interface to another: Use the pattern if (in addition to the two other ADAPTER uses): you need to use several existing subclasses, but it s impractical or impossible (multiple inheritance is not allowed) to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class 18.7 18.8
Formal Participants Target defines the domain-specific interface that Client uses (Shape in the above example) Client collaborates with objects conforming to the Target interface (DrawingEditor) Adaptee defines an existing interface that needs adapting (TextView) adapts the interface of Adaptee to the Target interface (TextShape) Clients call operations on an instance. In turn, the adapter calls Adaptee operations that carry out the request. s Adapt a ArrayedStack and LinkedStack to Stack interface. An abstract class AStack has four methods: push() pop() top() isempty() and it has two subclasses ArrayedStack and LinkedStack. Only adapts a class and all its parents, not all its subclasses Lets override some of Adaptee s behavior Only one object, hence no additional pointer indirection is needed to get to the adaptee Lets a single work with many Adaptees Makes it harder to override Adaptee behavior as the may not know which Adaptee it is working with Harder to override Adaptee behavior (it will require subclassing Adaptee and making refer to the subclass rather than the Adaptee itself) Draw or sketch the solution and relate to the UML diagram of ADAPTER pattern for a class doscussion. A Queue is just like a stack, except that additions take place at the opposite end to removals. It s a first in first out (FIFO) structure where the stack is a last in first out (LIFO) structure. In fact what the boss wants is a new top class called Dispenser, that has Stack and Queue as subclasses. Draw or sketch the solution, relate to the UML diagram of ADAPTER pattern and BRIDGE pattern for class discussion separately. Pluggable (introduced in Smalltalk, seen in JUnit design) is an adapter which adapts its interface dynamically to one of the several classes. It can adapt to the classes s recognise (determined by the constructor, or setparametrs() methods; also via use of reflections). 18.9 18.10 and dynamics Intent: Attach additional responsibilities to an object dynamically. s provide a flexible alternative to subclassing for extending functionality. Also known as: WRAPPER (as ADAPTER don t confuse) This pattern describes how to add responsibilities to objects dynamically (inheritance would be static and often unwieldy solution). DECORATOR is a structural pattern that composes objects recursively to allow an open-ended number of additional responsibilities. For example, a object containing a user interface component can add a decoration like a border or shadow to the component, or it can add functionality like scrolling and zooming. We can add two decorations simply by nesting one object within another, and so on for additional decorations. To accomplish this, each object must conform to the interface of its component and must forward messages to it. The DECORATOR can do its job (such as drawing a border around the component) either before or after forwarding a message. Use the pattern: to add responsibilities to individual objects dynamically and transparently (ie, without assuming that the client knows the contarct of the class, or without affecting other objects) for responsibilities that can be withdrawn when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing The run-time view of the decorated object: Using DECORATOR is like changing the skin of an object, or donning another piece of cloth 18.11 18.12
Formal Participants Component defines the interface for objects that can have responsibilities added to them dynamically (should be kept lightweight to avoid burdening concrete decorator class with unnecessary stuff"; Component s operations must be forwarded) ConcreteComponent defines an object to which additional responsibilities can be attached maintains a reference to a Component object and defines an interface that conforms to Component s interface Concrete adds responsibilities to the component forwards requests to its Component object. It may optionally perform additional operations before and after forwarding the request (+) More flexibility than static inheritance (properties can be added and remove at run-time; properties can be added repeatedly (fat border) (+) Avoids feature-laden classes high up in the hierarchy ( lazy design ) ( ) A decorator and its component are not identical (cannot rely on object identity when you use decorators) ( ) Too many (potentially) little look-alike objects (which differ only in the way they are interconnected, not in their class or in the value of their variables; these systems maybe easy to customize by those who understand them, they can be hard to learn and debug) The DECORATOR is commonly used in basic system frameworks: GUI components (Java s Swing), streams (Java s IO), fonts etc Intent: compose objects into tree structures to represent part-whole hierarchies. lets clients treat individual objects and compositions of objects uniformly. This is known as recursive composition. Component 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 implements child-related operations in the Component interface Leaf represents leaf objects in the composition. A leaf has no children defines behavior for primitive objects in the composition defines behavior for components having children stores child components mplements child-related operations in the Component interface Client manipulates objects in the composition through the Component interface 18.13 18.14 UML Diagram Uses Use the pattern if: You want to represent part-whole hierarchies of objects You want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in composite structure uniformly An example of a composite object and the book example: (+) It makes it easy to add a new kinds of components (+) It makes client simpler, since they do not have to know if they are dealing with a leaf or composite component ( ) It makes it harder to restrict the type of components of a composite (the design is overly general one cannot rely of the type system to enforce the inclusion constraints, and has to use run-time checks) Implementation issues A composite object knows its contained components (its children). Should components maintain a reference to their parent component? (depend on application, eg in CHAIN OF RESPONSIBILITY pattern) Transparency vs Safety where should the child management methods (add(), remove(), getchild()) be declared? In the component class (transparent, not safe, relies on run-time checks) or in composite class (gives compile-time safety, looses transparency leaf and composite have different interface). Should Component maintain the list of components that will be used by a composite object (should it be an instance variable of a component rather than composite?) Is child ordering important? (depends on application) How deleted components are dealt with (if no GC available) What is the best data structure to store components (depends on application) 18.15 18.16
Apply COMPOSITE PATTERN to work with arithmetic expressions built out of operators: + * / and constants. The operations that we are interested in are to evaluate arithmetic expressions, and print them, eg (1 + 2) * 4 Result: (1+2)*4=12 4 + ( 3 * 6 ) Result: 4+(3*6)=22 If successful, extend it to include another type of leaf variables. 18.17