- Flyweight: too many objects
it is very simple, you externalize some of the data in an object, so that you can pretend that you have more objects than you really do. However, this adds complexity to the interface for using such objects, because you must pass in additional information to method calls in order to tell the method how to find the externalized information.
- Decorator: too many classes
The use of layered objects to dynamically and transparently add responsibilities to individual objects is referred to as the decorator pattern.
Used when subclassing creates too many (& inflexible) classes
All decorators that wrap around the original object must have the same basic interface
Dynamic proxy/surrogate?
This accounts for the odd inheritance structure
Tradeoff: coding is more complicated when using decorators
Basic decorator structure
Connecting different types
1.Adapter
Adapter takes one type and produces an interface to some other type. When you’ve got this,
and you need that, Adapter solves the problem. The only requirement is to produce a that,
and there are a number of ways you can accomplish this adaptation.
//: adapter:SimpleAdapter.java
// "Object Adapter" from GoF diagram
package adapter;
import junit.framework.*;
class Target {
public void request() {}
}
class Adaptee {
public void specificRequest() {
System.out.println("Adaptee: SpecificRequest");
}
}
class Adapter extends Target {
private Adaptee adaptee;
public Adapter(Adaptee a) {
adaptee = a;
}
public void request() {
adaptee.specificRequest();
}
}public class SimpleAdapter extends TestCase {
Adaptee a = new Adaptee();
Target t = new Adapter(a);
public void test() {
t.request();
}
public static void main(String args[]) {
junit.textui.TestRunner.run(SimpleAdapter.class);
}
} ///:~
2. Bridge
but the goal of Bridge is to allow you to structure your code so that you can easily add new kinds of front-end objects which are implemented with functionality in new kinds of back-end objects. Thus, both front-end and back-end can vary independently of each other.
The front-end classes can have completely different interfaces from each other, and typically do. What they have in common is that they can implement their functionality using facilities from any number of different back-end objects. The back-end objects also don’t have the same interface. The only thing the back-end objects must have in common is that they implement the same kind of functionality – for example, a group of different ways to implement a graphics library or a set of different data-storage solutions.
Bridge is really a code-organization tool that allows you to add in any number of new frontend services that implement their operations by delegating to any number of back-end options. Using Bridge, you can accomplish this without the normal combinatorial explosion of possibilities that would otherwise occur. But keep in mind that the vector of change with Bridge is typically happening at coding time: it keeps your code organized when you are dealing with an increasing number of options for implementing functionality.