The Bridge Pattern is a structural pattern. It decouples the interface from the implementation. In C++, a simplified version is often used: the Pimpl Idiom.
Before I write about the Pimpl Idiom, here are the fact about the Bridge Pattern
The Bridge Pattern
- Decouples the interface from the implementation
Also known as
- Pimpl (pointer to implementation) Idiom
- The interface and the implementation can be extended
- A change of the interface of the implementation does not affect the client
- The implementation is hidden
- Defines the interface of the abstraction
- Has an object of type
- Implements or refines the interface of the
- Defines the interface of the implementation
- Implements the interface of the
The Bridge Pattern has two hierarchies. One hierarchy for the abstraction (interface), and one for the implementation. The client programs against the abstraction, and the abstraction uses the implementation. Consequently, different implementations of the abstraction interface and implementation interface can be used transparently. The Bridge Pattern provides big flexibility because the abstraction and implementation can be varied and exchanged during the program’s run time.
The Bridge Pattern is a powerful example exemplifying the combination of inheritance and composition. On one hand, it has two type hierarchies (inheritance); on the other hand, the abstraction has an implementation (composition).
The example shows a straightforward implementation of the Bridge Pattern.
Implementor (line 1) is the interface for the implementation hierarchy, and the class
Abstraction (line 2) is the interface of the abstraction. The instances
redefinedAbstraction2 get their implementation in its constructor (lines 3 and 4).
The following screenshot shows the output of the program.
- The Adapter Pattern implemented as an object adapter is similar to the Bridge Pattern but has a different intent. The Bridge Pattern’s purpose is to separate the interface from the implementation, but the adapter’s purpose is to modify an existing interface.
- The Abstract Factory can create and configure a Bridge.
In C++, a simplified version of the Bridge Pattern is often used.
The Pimpl Idiom
The key idea of the Pimpl Idiom is that the implementation of the class is hidden behind a pointer.
Here is a recipe for implementing the Pimpl Idiom:
- Move private data and member functions of the class (public class) to a separate class (pimpl class).
- Forward declare the pImpl class in the header of the public class.
- Declare pointer of type pimpl class in the public class.
- Define the pimpl class in the source file of the public class.
- Instantiate the pimpl class in the constructor of the public class.
- Member functions of the public class use those of the pimpl class.
Bartlomiej Filipek provides in his blog post “The Pimpl Pattern – what you should know” a nice example of the Pimpl Idiom:
Here are the key ideas of his implementation. I added a few line markers:
- The pimpl is a
std::unique_ptr<MyClassImpl> (line 1)
- The class support copy semantics and move semantics (lines 2 – 5)
- The private
Pimp()member functions of
constand a non-
MyClassImplpointers (lines 6 and 7)
You may ask yourself. What are the benefits of the Pimpl Idiom? It would be easier to merge the implementation
MyClassImpl into the abstraction
Pros and Cons
Let me start with the pros
- Binary Compatibility: When you change the implementation, this would not break the interface for the client using the abstraction.
- Compile Time: Changing the implementation does not require a recompilation of the client using the abstraction. Due to this fact, the Pimpl Idiom is often called a compilation firewall. This benefit is obsolete with modules in C++20
- Extensibility: It is pretty easy to exchange the implementation during run time. In general, there is no need for virtuality.
- Performance: The pointer indirection causes extra run-time costs.
- The Bix Six: You have to think about the Big Six (Read my post previous post the “C++ Core Guidelines: The Rule of Zero, Five, and Six” to get more details about the Big Six.). In particular, due to the fact that the abstraction has a
std::unique_ptr, it supports no copy semantics. This means in the concrete case.
- You have to implement copy semantics if you need it.
- When you implement copy semantics, you don’t automatically get move semantics and a default constructor.
- Memory Allocation: The Pimpl Idiom requires a memory allocation. This memory allocation may not be possible in embedded systems and may cause memory fragmentation.
Additionally, the Decorator Pattern is an often-used structural pattern from the book “Design Patterns: Elements of Reusable Object-Oriented Software”. Its job is to extend an object with responsibilities dynamically. Let me present the Decorator in my next post.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, and Bhavith C Achar.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.
|My special thanks to Embarcadero|
|My special thanks to PVS-Studio|
|My special thanks to Tipi.build|
|My special thanks to Take Up Code|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,