※设计模式※→☆结构型模式☆============Bridge模式（七）

模式概述

        Bridge模式应该是设计模式中比较复杂和理解性较难的模式了，当然，此模式是也是面向对象开发和面向对象设计中占有相当重要的席位，因此我们会有OO开发中经常使用到。在Bridge模式中我们使用组合(委托)和方式将抽象和实现进行解耦合，这样可以使抽象和实现都独立化。这说这里，也许我们想起了Build模式。没错，确实是这样的，Build模式也是使用组合(委托)的方式实现了"将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示"

        Build模式见：

                http://blog.csdn.net/xiaoting451292510/article/details/8330462

面向对象实际上就两句话：一是松耦合（Coupling），二是高内聚（Cohesion）。面向对象系统追求的目标就是尽可能地提高系统模块内部的内聚（Cohesion）、尽可能降低模块间的耦合（Coupling）。然而这也是面向对象设计过程中最为难把握的部分，大家肯定在OO系统的开发过程中遇到这样的问题：

 

• 1）客户给了你一个需求，于是使用一个类来实现（A）；
• 2）客户需求变化，有两个算法实现功能，于是改变设计，我们通过一个抽象的基类，再定义两个具体类实现两个不同的算法（A1和A2）；
• 3）客户又告诉我们说对于不同的操作系统，于是再抽象一个层次，作为一个抽象基类A0，在分别为每个操作系统派生具体类（A00和A01，其中A00表示原来的类A）实现不同操作系统上的客户需求，这样我们就有了一共4个类。
• 4）可能用户的需求又有变化，比如说又有了一种新的算法……..
• 5）我们陷入了一个需求变化的郁闷当中，也因此带来了类的迅速膨胀。

 

模式结构

 

模式讨论

在Bridge模式的结构图中可以看到，系统被分为两个相对独立的部分，左边是抽象部分，右边是实现部分，这两个部分可以互相独立地进行修改：例如上面问题中的客户需求变化，当用户需求需要从Abstraction派生一个具体子类时候，并不需要像上面通过继承方式实现时候需要添加子类。另外当上面问题中由于算法添加也只用改变右边实现（添加一个具体化子类），而右边不用在变化，也不用添加具体子类了。

我们可以在以下场景中使用Bridge模式

• 不希望在抽象类和他的实现部分之间有一个固定的绑定关系。
• 类的抽象和他的视线都想要能够通过生成子列的方式加以扩充的时候。
• 对于一个抽象的实现部分的修改不会对于外部的客户产生影响。
• 对与调用者隐藏抽象部分。

 

最后，无论模式多么优越，我们也需要根据实际的具体情况而慎重考虑。

模式实现

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
以后的笔记潇汀会尽量详细讲解一些相关知识的，希望大家继续关注我的博客。
本节笔记到这里就结束了。

潇汀一有时间就会把自己的学习心得，觉得比较好的知识点写出来和大家一起分享。
编程开发的路很长很长，非常希望能和大家一起交流，共同学习，共同进步。
如果文章中有什么疏漏的地方，也请大家指正。也希望大家可以多留言来和我探讨编程相关的问题。
最后，谢谢你们一直的支持~~~

       C++完整个代码示例（代码在VS2017下测试可运行）
代码及相关资料下载地址：
              https://gitee.com/arvinxt/DesignPattern