Degenerate Bridge Pattern Use Cases

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?

• What is it exactly? Is there a still need for the Implementor interface?
• What are examples or use cases of the pattern?
• Could the degenerate pattern turn into the non-degenerate Bridge pattern as the architecture evolves and more classes are added to the Implementor class hierarchy? The assumption here is the Implementor remains even if there is one ConcreteImplementor.

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 between Abstraction and Implementor. 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.