Download - PATTERNS04 - Structural Design Patterns
Structural Design PatternsMichael Heron
Introduction Structural design patterns emphasize
relationships between entities. These can be classes or objects.
They are designed to help deal with the combinatorial complexity of large object oriented programs. These often exhibit behaviours that are
not immediately intuitive.
Structural Patterns Common to the whole philosophy behind structural
patterns is the separation between abstraction and implementation. This is a good guideline for extensible design.
Structural patterns subdivide into two broad subcategories. Class structural patterns
Where the emphasis is on the relationship between classes
Object structural patterns The emphasis is on consistency of interaction and
realization of new functionality.
Façade When a model is especially complex, it can be
useful to add in an additional pattern to help manage the external interface of that model. That pattern is called a façade.
A façade sits between the view/controller and provides a stripped down or simplified interface to complex functionality. There are costs to this though in terms of
coupling and cohesion. A façade is a structural pattern.
Façade A façade provides several benefits
Makes software libraries easier to use by providing helper methods
Makes code more readable Can abstract away from the
implementation details of a complex library or collection of classes.
Can work as a wrapper for poorly designed APIs, or for complex compound relationships between objects.
Façade Examplepublic class FacadeExample { SomeClass one; SomeOtherClass two; SomeKindOfConfigClass three; public SomeOtherClass handleInput (String configInfo) { three = SomeKindOfConfigClass (configInfo) one = new SomeClass (configInfo); two = one.getSomethingOut (); return two; } }
Façade Examplepublic class FacadeExample { public SomeOtherClass handleInput (String configInfo) { return myFacade.doSomeMagic (configInfo); } }
public class Facade { SomeClass one; SomeOtherClass two; SomeKindOfConfigClass three; public SomeOtherClass doSomeMagic (String configInfo) { three = SomeKindOfConfigClass (configInfo) one = new SomeClass (configInfo); two = one.getSomethingOut (); return two; } }
Façade The more code that goes through the façade,
the more powerful it becomes. If just used in one place, it has limited benefit.
Multiple objects can make use of the façade. Greatly increasing the easy of development and
reducing the impact of change. All the user has to know is what needs to go
in, and what comes out. The façade hides the rest
Downsides This comes with a necessary loss of control.
You don’t really know what’s happening internally. Facades are by definition simplified interfaces.
So you may not be able to do Clever Stuff when blocked by one.
Facades increase structural complexity. It’s a class that didn’t exist before.
Facades increase coupling and reduce cohesion. They often have to link everywhere, and the set of
methods they expose often lack consistency
The Adapter The Adapter design pattern is used to
provide compatibility between incompatible programming interfaces. This can be used to provide legacy
support, or consistency between different APIs.
These are also sometimes called wrappers. We have a class that wraps around
another class and presents an external interface.
The Adapter Internally, an adapter can be as simple as
a composite object and a method that handles translations. We can combine this with other design
patterns to get more flexible solutions. For example, a factory for adapters Or adapters that work using the strategy
pattern. It is the combination of design patterns
that has the greatest potential in design.
Simple Exampleabstract class Shape { abstract void drawShape (Graphics g, int x1, int x2, int y1, int y2);}
public class Adapter { private Shape sh;
public void drawShape (int x, int y, int len, int ht, Graphics g) { sh.drawShape (g, x, x+ht, y, y+len); }}
Adapters and Facades What’s the difference between a façade and
an adapter? A façade presents a new simplified API to
external objects. An adapter converts an existing API to a
common standard. The Façade creates the programming interface
for the specific combination of objects. The adapter simply enforces consistency
between incompatible interfaces.
The Flyweight Object oriented programming languages
provide fine-grained control over data and behaviours. But that flexibility comes at a cost.
The Flyweight pattern is used to reduce the memory and instantiation cost when dealing with large numbers of finely-grained objects. It does this by sharing state whenever
possible.
Scenario Imagine a word processor.
They’re pretty flexible. You can store decoration detail on any character in the text.
How is this done? You could represent each character as an object. You could have each character contain its own
font object… … but that’s quite a memory overhead.
It would be much better if instead of holding a large font object, we held only a reference to a font object.
The Flyweight The Flyweight pattern comes in to reduce the state
requirements here. It maintains a cache of previously utilised configurations
or styles. Each character is given a reference to a configuration
object. When a configuration is applied, we check the cache to
see if it exists. If it doesn’t, it creates one and add it to the cache.
The Flyweight dramatically reduces the object footprint. We have thousands of small objects rather than
thousands of large objects.
Before and Afterpublic class MyCharacter { char letter; Font myFont; void applyDecoration (string font, int size); myFont = new Font (font, size); }}
public class MyCharacter { char letter; Font myFont; void applyDecoration (string font, int size); myFont = FlyweightCache.getFont (font, size); }}
Implementing a Flyweight The flyweight patterns makes no
implementation assumptions. A reasonably good way to do it is through a
hash map or other collection. Standard memoization techniques can be
used here. When a request is made, check the cache. If it’s there, return it. If it’s not, create it and put it in the cache and
return the new instance.
Limitations of the Flyweight Pattern Flyweight is only an appropriate design
pattern when object references have no context. As in, it doesn’t matter to what they are
being applied. A font object is a good example.
It doesn’t matter if it’s being applied to a number, a character, or a special symbol.
A customer object is a bad example. Each customer is unique.
The Composite Pattern We often have to manipulate collections of
objects when programming. The composite pattern is designed to simplify this.
Internally, it represents data as a simple list or other collection. Requires the use of polymorphism to assure
structural compatability. Externally it presents an API to add and remove
objects. And also to execute operations on the collection as
a whole.
The Composite Patternpublic class ShapeCollection implements Shape() { ArrayList shapes = new ArrayList(); void addShape (Shape s) { shapes.Add (s); } void removeShape (Shape s) { shapes.Remove (s); } void draw() { foreach (Shape s in shapes) { s.draw(); } } void setColour (Colour c) { foreach (Shape s in shapes) { s.setColour (c); } }}
The Composite Patternpublic MainProgram() { Circle circle = new Circle(); Rectangle rect = new Rectangle(); Triangle tri = new Triangle(); ShapeCollection myCollection = new ShapeCollection(); ShapeCollection overallScene = new ShapeCollection(); myCollection.addShape (circle); myCollection.addShape (rect);
overallScene.addShape (myCollection); overallScene.addShape (tri); myCollection.setColour (Colour.RED); overallScene.draw(); }
Why Use Composite? Sometimes we need to be able to perform
operations on groups of objects as a whole. We may wish to move a group of shapes in a
graphics package as one example. These often exist side by side with more
primitive objects that get manipulated individually.
Having handling code for each of these conditions is bad design.
The Composite The composite allows us to treat
collections and individual objects through one consistent interface. We don’t need to worry about which we are
dealing with at any one time. It works by ensuring that the collection
implements the common interface shared by all its constituent bits. The relationship is recursive if done
correctly.
Summary Structural patterns are the last of the families of
design patterns we are going to look at. We use an adapter to deal with incompatible APIs. We use a bridge to decouple abstraction from
implementation. Implementation is very similar to strategy, only the
intent is unique. Flyweight patterns are used to reduce processing
and memory overheads. Composites are used to allow recursive and
flexible aggregate manipulation of objects.