An instance of AdapterPattern from the GangOfFour DesignPatterns book:

-----

BobbyWoolf writes (E-mail to PatternsDiscussion 2000/4/7):

You're using Java. You have two classes that aren't yours (so you can't
modify them). You want to write some client code that will use them
interchangeably. How do you specify their type? You can't specify the
class; there's more than one of them. You can't specify their common
superclass; it's too general (perhaps it's java.lang.Object). You can't
specify their common interface; either they don't have one or it's too
general.

''Therefore'', apply a common specialization of the Adapter
pattern. Implement the interface that your client needs. For each
third-party class that you're trying to use, create an adapter class.
The adapter should implement the interface; code each interface message
to delegate to the proper messages in the third-party class. The client
should reference the interface. When the client needs to use an instance
of a third-party class, wrap it with an instance of the corresponding
adapter class and use the instance via the interface. The adapters allow
the client to use heterogeneous classes interchangeably through a
homogeneous interface without having to modify the original classes.

----

Is this a pattern, or is it just an appearance of Adaptor in
some RunTimeTypeChange pattern language?

''It's a variation of the AdapterPattern in the GangOfFour DesignPatterns book.''

The book assumes that you control one of the classes of interest, and are trying to make some incompatible class conform.
The idea in this note generalizes the AdapterPattern idea.


----

It is the ExternalPolymorphism pattern documented by Doug Schmidt, and available online at http://www.cs.wustl.edu/~schmidt/External-Polymorphism.ps.gz.

'''See also:''' AdapterPattern

----
CategoryPattern CategoryStructuralPatterns CategoryInterface