The Basics

The defining properties of the technique are

the separation of public interface and private implementation and then
implementation hiding.

In [6] they are described as the "intent" and the "applicability" of the Bridge incarnation of the pattern.

	Important
The Object-Oriented programming paradigm -- the association between data and behavior -- is realized in the fundamental concept of an object or a class and is routinely seen and implemented as such -- one class. That one-class approach is not exactly ideal for the purposes mentioned in the Introduction. However, the fault-line where the conventional class is split in two is not between data and behavior. It is, rather, between public interface (public behavior) and private implementation (private data and behavior) -- two different (external and internal) views of a system. They serve different purposes and are better managed when kept separate. The Pimpl technique seems to fit that objective better with actual rather than notional separation.

Important

The Object-Oriented programming paradigm -- the association between data and behavior -- is realized in the fundamental concept of an object or a class and is routinely seen and implemented as such -- one class.

That one-class approach is not exactly ideal for the purposes mentioned in the Introduction. However, the fault-line where the conventional class is split in two is not between data and behavior. It is, rather, between public interface (public behavior) and private implementation (private data and behavior) -- two different (external and internal) views of a system. They serve different purposes and are better managed when kept separate. The Pimpl technique seems to fit that objective better with actual rather than notional separation.

The separation results in two classes/objects -- the Handle and the Body ([5]), the interface proxy and the actual implementation, a level of indirection. Conceptually (from the design perspective) that "decouples an abstraction from its implementation" ([6]). In reality (from the implementation perspective), however, those two classes/objects complement each other and inherently coupled. They are inseparable yin and yang, part and parcel of the Pimpl idiom. Consequently, the relationship between those two objects is an important part of the idiom (at the very least from the practical angle). That relationship might exhibit

) the pointer/shared properties where several proxy objects are sharing access to the same underlying implementation object (similar to std::shared_ptr behavior);
) the exclusive-ownership properties where every proxy represents/owns its own implementation object; such exclusive ownership might be further of
- ) the unique-ownership nature (i.e. non-copyable, similar to std::unique_ptr behavior) or
- ) the copied-ownership nature where copying of the proxy creates a new (copied) implementation to go with the new (copied) proxy;
) other behavioral policies such as copy-on-write;
) implementation-specific policies such as in-place-implementation (to avoid dynamic memory allocation), etc.

Taking care of all that variability on case-by-case basis might be laborious and error-prone. Replacing one relationship policy with another in the middle of the development (or maintenance) cycle might be even more disruptive. This proposed policy-based library considerably reduces (if not eliminates) the impact and the hassle.