All Packages Class Hierarchy This Package Previous Next Index
This provides the Exposed Delegator Pattern for parts. This pattern allows clients to get and use a part's Delegate for certain responsiblities. This greately reduces the size and complexitiy of some parts, allows loose coupling between the Delegate and it's host, etc. Note how the host can provide its own Delegate, or it can be set by a Mediator. This pattern allows a slew of radical framework improvements.
One example is a Cell has a "StateCommandable" Delegate which is the CellLifecycle. The Cell never even knows it has this Delegate.
A great advantage is when looping through parts in a collection to check for a certain interface, say InterfaceA. As Steve pointed out, by doing the Delegate check first we allow the Delegate to shadow the part's InterfaceA. The algorithm is:
1. If the part implements Delegator and has the InterfaceA Delegate, use it.2. If the part implements the InterfaceA, use that.
3. Otherwise assume the part doesn't support InterfaceA.
The greatest good is achieved when delegates are provided for a class and the class never even knows they're there. These "hidden" delegates usually have a reference to the delegator. The delegator should not use them for anything, and pretend they're not even there.
Hidden delegates should be kept in something like a Hashtable.
Since we are planning for mostly this, we return an
Enumeration instead of a String[] for the
delegate names. This makes the implementation easier.
public abstract Object getDelegate(String delegateName)
public boolean hasDelegate();
which would be redundant and a perfromance hit since if true you
must get the delegate anyhow.
public abstract void setDelegate(String delegateName,
Object delegate)
public abstract Enumeration getDelegateNames()
All Packages Class Hierarchy This Package Previous Next Index