Object-Based Remodularization (a.k.a. Programming with Adapters )

Almost two years ago I wrote about "Programming with Adapters". The observation was that a lot of menial work in programming covers the transformation of one type into another. It is simply embarassing the amount of time spent doing this kind of activity. If technology were available to reduce this then it would compensate for a lot of shortcomings of OO in relation to reusability.

The PyProtocols project describes an adaptation protocol:

adapt(

component, protocol, [, default])

Return an implementation of protocol (a protocol object) for component (any object). The implementation returned may be component, or a wrapper that implements the protocol on its behalf. If no implementation is available, return default. If no default is provided, raise protocols.AdaptationFailure.

The component adaptation process performed by adapt() proceeds in four steps:

1. If protocol is a class or type, and component is an instance of that class or type, the component is returned unchanged. (This quickly disposes of the most trivial cases).

2. If component has a __conform__ method, it is called, passing in the protocol. If the method returns a value other than None, it is returned as the result of adapt().

3. If protocol has an __adapt__ method, it is called, passing in component. If the method returns a value other than None, it is returned as the result of adapt().

4. Perform default processing as described above, returning default or raising protocols.AdaptationFailure as appropriate.

This is the general perscription and its implemented in Python. However, is there something equivalent to this in the Java world? Fortunately there is one, this adaptation protocol albeit in a less general form is used throughout the 1,903,219 lines of code found in the Eclipse platform. In otherwords, its not just theoretical fancy, it is actually applied in the real world in anger!

The key component is the interface IAdaptable. Take note of the number of interfaces that extend from it. The Eclipse adaptation protcol based on the general protocol above goes like this:

public interface IAdaptable {
    Object getAdapter(Class adapter);
}

The component adaptation process performed by getAdapter() proceeds in four steps:

1. If adapter is an interface that this implements then return this unchanged. (Note: This trivial case is usually not done by most implementors of this method ).
2. If the method can find a matching adapter, return an instance that implements the adapter otherwise call getAdaptor() in PlatformObject.
3. The PlatformObject calls Platform.getAdapterManager().getAdapter(this, adapter); If the AdapterManager finds a match then create and return an instance that implemnts adaptor. Otherwise return null. The AdapterManager provides a mechanism to dynamically register AdapterFactory's.
4. The getAdapter method returns null if no matching adapter is found.

Adapter Oriented Programming allows for new interfaces to be associated to class instances dynamically. In contrast the Adaptive Object Model allowed both data and behavior to dynamically change this dynamicity was on a per "class" basis. Adapter Oriented Programming adds behavior on a per instance basis. This simplicity of this protocol disguises its actual power which is reflected in the Eclipse environment. For example, actions that were designed for resources (i.e. content diffing) can reused against Java types.

However the most interesting thing of this can be discerned from the research in "Fluid AOP".

The advantage of object-based remodularization is twofold. First, we have fine-grained control over the integration process because we can choose for each object whether it should be part of a collaboration or not. Second, the same object (or set of objects) can participate in multiple component instances.

Object-based remodularization (i.e. OBR), a nice distinctive term to capture the ideas of Adapter Oriented Programming, after all AOP has already been co-opted by another technology. Its surprising that this technique has been under our noses for all this time and we never even noticed!