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