Bridge (bridging)-Object-structured mode

1. Intentions

Separate the abstract part from its implementation, so that they can all change independently.

2. Motivation

A bridge between an abstract class and its implementation, so that they can vary independently.

3. Applicability

• You do not want to have a fixed binding relationship between the abstraction and its implementation section. This may be because the implementation portion of the program runtime can be selected or switched.
• The abstraction of a class and its implementation parts should be augmented by the way in which subclasses are generated. Bridging mode allows you to combine different abstract interfaces and implementation parts, and expand them separately.
• Modifications to an abstract implementation section should not have an impact on the customer, that is, the customer code is not required to recompile.
• Completely hides the abstract implementation part from the customer. The representation of a class in C + + is visible in the class interface.
• There are many classes to build, so a class hierarchy illustrates that you must break up an object into two parts.

4. Structure

5. Code examples

#include <memory>classAbstactionimpl;classabstration{ Public:    void VirtualOperaion () =0; void VirtualSetimpl (std::shared_ptr<abstactionimpl>& Pimpl) =0;protected: Std::shared_ptr<AbstactionImpl>M_pimpl;};classRedefinedabstration: Publicabstration{ Public:    voidoperaion (); voidSetimpl (std::shared_ptr<abstactionimpl>&pimpl);};

classabstactionimpl{ Public:    void VirtualOperationimpl () =0;};classConcreteimplentora: Publicabstactionimpl{ Public:    voidOperationimpl ();};classConcreteimplentorb: Publicabstactionimpl{ Public:    voidOperationimpl ();};

 #include  abstration.h   "  #include  "  implentor.h   void   Redefinedabstration::operaion () {M_pimpl ->operationimpl ();}  void  Redefinedabstration::setimpl (Std::shared_ptr<abstactionimpl>& PImpl) {m_ Pimpl  = Pimpl;}  

#include <iostream>"Implentor.h"void  Concreteimplentora: : Operationimpl () {    std::cout<<"concreteimplenora exectued" << Std::endl;} void Concreteimplentorb::operationimpl () {    std::cout<<"Concreteimplentorb exectued"<<Std::endl;}

#include <memory>#include"Abstration.h"#include"Implentor.h"intMain () {std::shared_ptr<AbstactionImpl> Pconcreteimpla (NewConcreteimplentora); Std::shared_ptr<AbstactionImpl> PCONCRETEIMPLB (NewConcreteimplentorb); Std::shared_ptr<RedefinedAbstration> Predefinedabstration (Newredefinedabstration); Predefinedabstration-Setimpl (PCONCRETEIMPLA); Predefinedabstration-operaion (); Predefinedabstration-Setimpl (PCONCRETEIMPLB); Predefinedabstration-operaion ();  while(1);}

6. Test results

7. Effects

• The separation interface and its implementation part an implementation is not necessarily bound to an interface. The implementation of an abstract class can be configured at runtime, and an object can even change its implementation at run time. Separating abstraction and implementor helps reduce the dependency on implementing partial compile time, and when you change an implementation class, you do not need to recompile the Abstaction class and its client programs.
• Increased scalability allows the abstraction and implementor hierarchies to be expanded independently.
• The implementation details are transparent to the customer and the implementation details are hidden from the customer.

Bridge (bridging)-Object-structured mode