Consequences

 

The External Polymorphism pattern has the following benefits:

• Transparent - Classes that were not originally designed to work together can be extended relatively transparently so they can be treated polymorphically. In particular, the object layout of existing classes need not change by adding virtual pointers.
• Flexible - It's possible to polymorphically extend non-extensible data types such as int or double when the pattern is implemented in a language supporting parameterized types (e.g., C++ templates).
• Peripheral - Because the pattern establishes itself on the fringes of existing classes, it's easy to use conditional compilation to remove all trace of this pattern. This feature is particularly useful for systems that use the External Polymorphism pattern only for debugging purposes.

This pattern has the following drawbacks:

• Instability - The methods in the Common and ConcreteCommon must track changes to methods in the Concrete classes.
• Inefficient - Extra overhead due to multiple forwarding from virtual methods in the ConcreteCommon object to the corresponding methods in the Concrete object. However, judicious use of inline (e.g., within SignatureAdapter and Concrete) can reduce this overhead to a single virtual method dispatch.

There is another consideration when using this pattern:

• Possibility of inconsistency - Externally Polymorphic methods are not accessible through pointers to the concrete classes, e.g., using the example in Section 2 it's not possible to access dump through a pointer to SOCK_Stream. In addition, it is not possible to access other methods from the concrete class through a pointer to ConcreteCommon.