patterns

The Bridge Pattern

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.

 patterns

Before I write about the Pimpl Idiom, here are the fact about the Bridge Pattern

The Bridge Pattern

Purpose

  • Decouples the interface from the implementation

Also known as

  • Handle/Body
  • Pimpl (pointer to implementation) Idiom

Applicability

  • 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

Structure

Bridge

 

Abstraction

 

Rainer D 6 P2 500x500Modernes C++ Mentoring

Be part of my mentoring programs:

  • "Fundamentals for C++ Professionals" (open)
  • "Design Patterns and Architectural Patterns with C++" (open)
  • "C++20: Get the Details" (open)
  • "Concurrency with Modern C++" (starts March 2024)
  • Do you want to stay informed: Subscribe.

     

    • Defines the interface of the abstraction
    • Has an object of type Implementor

    RedefinedAbstraction

    • Implements or refines the interface of the Abstraction

    Implementor

    • Defines the interface of the implementation

    ConcreteImplementor

    • Implements the interface of the Implementor

    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).

    Example

    The example shows a straightforward implementation of the Bridge Pattern.

    // bridge.cpp
    
    #include <iostream>
    
    class Implementor {                           // (1)
    public:
        virtual void implementation() const = 0;
    
        virtual ~Implementor() = default;
    };
     
    class ImplementorA: public Implementor {
    public:
        ImplementorA() = default;
     
        void implementation() const {
            std::cout << "ImplementatorA::implementation" << '\n';
        }
    };
     
    class ImplementorB: public Implementor {
    public:
        ImplementorB() = default;
    
        void implementation() const {
            std::cout << "ImplementatorB::implementation" << '\n';
        }
    };
    
    class Abstraction {                           // (2)      
    public:
        virtual void function() const = 0;
        virtual ~Abstraction() = default;
    };
    
    class RefinedAbstraction: public Abstraction {
    public:
        RefinedAbstraction(Implementor& impl) : 
    		implementor(impl) {
        }
     
        void function() const {
            std::cout << "RefinedAbstraction::function\n";
            implementor.implementation();
        }
    private:
        Implementor& implementor;
    };
     
    int main() {
    
        std::cout << '\n';
    
        ImplementorA implementorA;
        ImplementorB implementorB;
     
        RefinedAbstraction refinedAbstraction1(implementorA);  // (3)
        RefinedAbstraction refinedAbstraction2(implementorB);  // (4)
    
        Abstraction *abstraction1 = &refinedAbstraction1;
        Abstraction *abstraction2 = &refinedAbstraction2;
    
        abstraction1->function();
    
        std::cout << '\n';
    
        abstraction2->function();
    
        std::cout << '\n';
    
    }
    

     

    The class Implementor (line 1) is the interface for the implementation hierarchy, and the class Abstraction (line 2) is the interface of the abstraction. The instances redefinedAbstraction1 and redefinedAbstraction2 get their implementation in its constructor (lines 3 and 4).

    The following screenshot shows the output of the program.

    bridgeExample

    Related Patterns

    • 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:

    1. Move private data and member functions of the class (public class) to a separate class (pimpl class).
    2. Forward declare the pImpl class in the header of the public class.
    3. Declare pointer of type pimpl class in the public class.
    4. Define the pimpl class in the source file of the public class.
    5. Instantiate the pimpl class in the constructor of the public class.
    6. 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:

    // class.h
    class MyClassImpl;
    class MyClass
    {
    public:
        explicit MyClass();
        ~MyClass(); 
    
        // movable:
        MyClass(MyClass && rhs) noexcept;                          // (2)
        MyClass& operator=(MyClass && rhs) noexcept;               // (3)
    
        // and copyable
        MyClass(const MyClass& rhs);                               // (4)
        MyClass& operator=(const MyClass& rhs);                    // (5)
    
        void DoSth();
        void DoConst() const;
    
    private:
        const MyClassImpl* Pimpl() const { return m_pImpl.get(); }  // (6)
        MyClassImpl* Pimpl() { return m_pImpl.get(); }              // (7)
    
        std::unique_ptr<MyClassImpl> m_pImpl;                       // (1)
    };
    
    // class.cpp
    class MyClassImpl
    {
    public:
        ~MyClassImpl() = default;
    
        void DoSth() { }
        void DoConst() const { }
    };
    
    MyClass::MyClass() : m_pImpl(new MyClassImpl()) 
    {
    
    }
    
    MyClass::~MyClass() = default;
    MyClass::MyClass(MyClass &&) noexcept = default;
    MyClass& MyClass::operator=(MyClass &&) noexcept = default;
    
    MyClass::MyClass(const MyClass& rhs)
        : m_pImpl(new MyClassImpl(*rhs.m_pImpl))
    {}
    
    MyClass& MyClass::operator=(const MyClass& rhs) {
        if (this != &rhs) 
            m_pImpl.reset(new MyClassImpl(*rhs.m_pImpl));
    
        return *this;
    }
    
    void MyClass::DoSth()
    {
        Pimpl()->DoSth();
    }
    
    void MyClass::DoConst() const
    {
        Pimpl()->DoConst();
    }
    

     

    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 MyClass return a const and a non-const MyClassImpl pointers (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 MyClass.

    Pros and Cons

    Let me start with the pros

    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.

    Cons

    • 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.

    What’s Next?

    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, 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, Bhavith C Achar, Marco Parri Empoli, moon, Philipp Lenk, Hobsbawm, and Charles-Jianye Chen.

    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
    My special thanks to SHAVEDYAKS

    Seminars

    I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

    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++
    • C++20

    Online Seminars (German)

    Contact Me

    Modernes C++ Mentoring,

     

     

    0 replies

    Leave a Reply

    Want to join the discussion?
    Feel free to contribute!

    Leave a Reply

    Your email address will not be published. Required fields are marked *