I'm looking for elaboration on the Degenerate Bridge pattern.
GoF's Design Patterns book mentions a "degenerate case of the Bridge pattern" that has a "one-to-one relationship between Abstraction and Implementor", but what is the motivation for using such a pattern?
This is all explained in the Implementation issues #1.
Only one Implementor. In situations where there's only one implementation, creating an abstract
Implementor
class isn't necessary. This is a degenerate case of the Bridge pattern; there's a one-to-one relationship betweenAbstraction
andImplementor
. Nevertheless, this separation is still useful when a change in the implementation of a class must not affect its existing clients— that is, they shouldn't have to be recompiled, just relinked.Carolan [Car89] uses the term "Cheshire Cat" to describe this separation. In C++, the class interface of the
Implementor
class can be defined in a private header file that isn't provided to clients. This lets you hide an implementation of a class completely from its clients.
So...
what is the motivation for using such a pattern?
"...this separation is still useful when a change in the implementation of a class must not affect its existing clients..." The example given is highly specific to compiled (as opposed to interpreted) languages, like C++. Still it's the same common theme that runs throughout the GoF book: composition is more flexible than inheritance.
Is there a still need for the
Implementor
interface?
"...creating an abstract Implementor
class isn't necessary."
What are examples or use cases of the pattern?
Carolan [Car89] refers to: J. Carolan. Constructing bullet-proof classes. In Proceedings C++ at Work '89. SIGS Publications, 1989.
I'm not sure if that exact paper is available online; but Google shows a few promising results related to the title, including Interpreting "Supporting the 'Cheshire Cat' Idiom".
Could the degenerate pattern turn into the non-degenerate Bridge pattern...
Anything could turn into anything, if you change the code, right? An abstract Implementor
class certainly makes the change easier, though.