Question

我尝试研究 Bridge 设计模式，并偶然发现了各种在线答案。最终，我想我掌握了窍门。如果对此有误，请随时纠正我，但是我可以使用Bridge模式将特定数据与如何呈现该特定数据分开。

当我了解到这一点时，令我惊讶的是，我已经熟悉了相同性质的东西，即MVC模型，其中指出我们有一个模型（数据）和一个视图（用于渲染的UI）以及一个查询模型以支持视图的控制器。

那么，这两者之间是否存在关联？或者仅仅是我对Bridge模式感到困惑？如果Bridge模式还有其他内容，请告诉我。

Answer 1

Bridge是一种通用模式，扩展了我们通常实现多态性的方式。例如，考虑图形的规范示例。

Abstract Class Shape(
    abstract function draw();
)

Class Circle extends Shape(
    draw(){ /*draw a circle*/}
)

Class Square extends Shape(
    draw(){ /*draw a square*/}
)

现在，我们可以制作一个形状数组（由正方形和圆形组成），并使用每个元素上的shape-> draw（）告诉数组中的每个对象自己绘制。（所有伪代码）

现在假设在不同系统上绘制圆形和正方形的方式是不同的。我们可以添加新的抽象draw（）函数，例如drawWindows（）和drawXwin（）以及相应的实现。

或者，我们可以使用Bridge并传入一个实现drawAPI的对象（并且我们可以有许多具体的子类以不同的方式绘制。

Abstract Class Shape(
    protected drawAPI;         // object that implements drawAPI

    abstract function draw();

    Shape( drawAPIin){  // constructor
     drawAPI =  drawAPIin;
    }
)

Class Circle extends Shape(

    draw(){ drawAPI->draw();}
)

Class Square extends Shape(
    draw(){ drawAPI->draw();}
)

现在我们仍然可以制作形状的数组（由正方形和圆形组成），并使用每个元素上的shape-> draw（）告诉数组中的每个对象自己绘制，但是这次将根据draw （）将drawAPI对象的（）传递给Shape的构造函数（得到它吗？:-)）。无论如何，这是一种非常灵活的方法。

将此内容压缩为MVC，这是一种专用模式，通常用于分离数据存储/检索（模型的功能），数据显示和用户输入（视图的功能）以及在模型和视图之间（控制器的功能）。 MVC模式有多种变体，可以在各种前端和后端Web开发框架中看到。

正如您所看到的，尽管您指出可能存在重叠点，但Bridge Pattern和MVC的意图却大不相同。尽管将它们视为同一模式的不同名称可能并不完全正确，但正如您所指出的那样，存在连接，这与大多数GoF模式重叠并且以多种方式连接一样。

当我们提高对问题的思考的抽象水平时，想法和解决方案通常看起来合并并且看起来很相似。但是细节决定成败，一个好的起点就是仔细查看每种模式的意图，以了解它们之间的差异。

MVC模型和Bridge设计模式之间是否存在联系？

1 个答案: