Structure Patters: Bridge and Flyweight

CSCI 3132 Summer 2011

Introducing the Bridge Pa1ern

Intent
To decouple an abstrac7on from its implementa7on so that the two can vary independently. What does it mean?
Decouple: have things behave independently from each other. Abstrac7on: how things are related to each other conceptually.

An Example
A simple problem
Drawing shapes
Rectangles

Two dierent drawing programs

Example (Contd)
Proper use of inheritance
We dont want the code that draws the rectangles to worry about what type of drawing program it should use. V1Rectangle uses DP1 V2Rectangle uses DP2
class V1Rectangle : public Rectangle! {! public:! V1Rectangle(double x1, double y1, double x2, double y2) : ! Rectangle(x1, y1, x2, y2){} void drawLine( double x1, double y1, double x2, double y2){! DP1::draw_a_line( x1, y1, x2, y2);! }! public:! ~V1Rectangle(void);! };!

A Design using Inheritance

Changing requirements: add a new shape - circle

Sequence Diagram

Any Problem?
Combinatorial explosion
Another new drawing program
Six dierent kinds of Shapes
2 Shape concepts 7mes three drawing programs

Another type of Shape

Nine dierent kinds of Shapes
3 Shape concepts 7mes three drawing programs

Learning the Bridge Pa1ern: An Example

Reason
Tightly coupled
The abstrac7on ( the kinds of Shapes ) and the implementa7on ( the drawing programs)

The Bridge pa1ern

To decouple an abstrac7on from its implementa7on so that the two can vary independently

An Observa7on
The way to look at design pa1erns
Focus on the context of the pa1ern the problem it is trying to solve
Not on the solu7ons the pa1erns oer

The bridge pa1ern

An abstrac7on that has dierent implementa7ons Allow the abstrac7on and the implementa7on to vary independently of each other

Learning the Bridge Pa1ern: Deriving It

Step 1 : nd out what varies and encapsulate it. Step 2: Represent the varia7ons.

10

Learning the Bridge Pa1ern: Deriving It

Step 3. Tie the classes together
What uses what?

11

Learning the Bridge Pa1ern: Deriving It

Expanding the design

12

Separa7on of abstrac7on and implementa7on

Separate the abstraction class hierarchy from the implementation class hierarchy and use delegation as a bridge between the two.

13

Class Diagram
Generic structure of the Bridge pa1ern

14

The Par7cipants

Abstraction defines the abstractions interface RefinedAbstraction extends the interface defined by Abstraction Implementor defines the interface for implementation classes; can be different from Abstraction interface. Typically, Implementor provides only primitive operations, and Abstraction defines higher-level operations based on these primitives. ConcreteImplementor implements the Implementor interface and defines its concrete implementation.
15

Using the Bridge Pa1ern

The Bridge pa1ern oZen incorporates the Adapter pa1ern
Compound design pa1erns

Instan7a7ng the objects of the Bridge pa1ern

The objects represen7ng the abstrac7on were given their implementa7on while being instan7ated.

Basic strategies for dealing with varia7on:

Find what varies and encapsulate it. Favor aggrega7on over inheritance.

16

Applicability
Use the bridge when:
You want to avoid a permanent binding between an abstrac7on and its implementa7on. Both the abstrac7ons and their implementa7ons should be extensible by subclassing. Changes in the implementa7on of an abstrac7on should have no impact on clients (i.e. code should not have to be recompiled). You want to share an implementa7on among mul7ple objects, and want to hide this from the client.

17

Benets in using Bridge Pa1ern

Decoupling abstrac7on from implementa7on Reduc7on in the number of sub classes. Cleaner code and Reduc7on in executable size. Interface and implementa7on can be varied independently. Abstrac7on and implementa7on can be extended independently. Loosely coupled client code.

18

Bridge and Adapter

The Bridge pa1ern is designed to separate a classs interface from its implementa7on, so that you can vary or replace the implementa7on without changing the client code. Adapter makes things work aZer theyre designed; Bridge makes them work before they are. Bridge is designed up-front to let the abstrac7on and the implementa7on vary independently. Adapter is retro1ed to make unrelated classes work together.

19

Bridge and Strategy

OZen, the Strategy Pa1ern is confused with the Bridge Pa1ern. Even though, these two pa1erns are similar in structure, they are trying to solve two dierent design problems. Strategy is mainly concerned in encapsula7ng algorithms, whereas Bridge decouples the abstrac7on from the implementa7on, to provide dierent implementa7on for the same abstrac7on.

20

Bridge and Abstract Factory

The Abstract Factory pa1ern can be used by the Bridge pa1ern to decide which implementa7on class to instan7ate for an abstrac7on object.

21

Flyweight

22

Problem of redundant objects

Flyweight: a class that has only one instance for each unique state problem: existence of redundant objects can bog down system
many objects have same state example: File objects that represent the same le on disk
new File("mobydick.txt") new File("mobydick.txt") new File("mobydick.txt") ... new File("notes.txt") new File("notes.txt")

23

Flyweight pa1ern
yweight: an assurance that no more than one instance of a class will have iden7cal state achieved by caching iden7cal instances of objects to reduce object construc7on similar to singleton, but has many instances, one for each unique-state object useful for cases when there are many instances of a type but many are the same can be used in conjunc7on with Factory pa1ern to create a very ecient object-builder

24

Flyweight and Strings

Flyweighted strings
Java Strings are yweighted by the compiler wherever possible can be yweighted at run7me with the intern method
public class StringTest { public static void main(String[] args) { String fly = "fly", weight = "weight"; String fly2 = "fly", weight2 = "weight"; System.out.println(fly == fly2); System.out.println(weight == weight2); // true // true

String distinctString = fly + weight; System.out.println(distinctString == "flyweight"); // false String flyweight = (fly + weight).intern(); System.out.println(flyweight == "flyweight"); // true

25

Implemen7ng a Flyweight
yweigh7ng works best on immutable objects immutable: cannot be changed once constructed class pseudo-code sketch:
public class Flyweighted { sta7c map or table of instances private constructor sta7c method to get an instance if we have created this type of instance before, get it from map and return it otherwise, make the new instance, store and return it }
26

Flyweight sequence diagram

27 27

Class before yweigh7ng

A class to be yweighted
public class Point { private int x, y; public Point(int x, int y) { this.x = x; this.y = y; } public int getX() { return this.x; } public int getY() { return this.y; } public String toString() { return "(" + this.x + ", " + this.y + ")"; } }
28

Class aZer yweigh7ng

A class that has been yweighted!
public class Point { private static Map instances = new HashMap(); public static Point getInstance(int x, int y) { String key = x + ", " + y; if (instances.containsKey(key)) // re-use existing pt return (Point)instances.get(key); Point p = new Point(x, y); instances.put(key, p); return p; } private final int x, y; // immutable private Point(int x, int y) { ...

29

GoF Pa1erns Summary

Crea3onal Pa7erns abstract the instan7a7on process. They help make a system independent of how its objects are created, composed, and represented. Structural Pa7erns are concerned with how classes and objects are composed to form larger structures. Behavioral Pa7erns are concerned with algorithms and the assignment of responsibili7es between objects. Behavioral pa1erns describe not just pa1erns of objects or classes but also the pa1erns of communica7on between them.
30

Design Space for GoF Pa1erns

Scope: domain over which a pattern applies Purpose: reflects what a pattern does
31

GoF Pa1ern Rela7onships

32