桥牌vs策略模式

本文关键字：模式 策略 vs 桥牌 | 更新日期: 2023-09-27 18:01:21

我知道，这个问题被问了很多次，但我做了一些研究，仍然不明白，也许你可以帮助我:如前所述，UML几乎是相同的。实现和思想也或多或少是相同的:不是子类型，而是定义一个接口，它封装了一些逻辑，并让它传递给抽象。所以，即使是微软博客的家伙

https://blogs.msdn.microsoft.com/gyanjadal/2015/01/05/difference-between-strategy-and-bridge-patterns/表示:

简单的答案是"它们相似但不同"。的实现是相似的，但意图不同。给打个比方，城市公交车和校车都是类似的交通工具，但是它们有不同的用途。一种是用来运送人的在城市的各个部分之间提供通勤服务。另一个是用于接送孩子上学。

"如果它听起来像鸭子，看起来像鸭子，但它想成为一只天鹅，它可以是它们中的任何一个"，这就是我在这里读到的。

由于我仍然没有得到它，所以我进一步挖掘:

https://social.msdn.microsoft.com/forums/en us/08775d39 - 2 de0 - 4598 - 8872 - df21f681b7b3/strategy - vs -桥- patterns?forum=architecturegeneral

这个线程也没有添加任何新内容，除了:

在我看来，它们表面上看起来是一样的。主要的我看到的不同之处在于在桥牌模式中抽象是对象的一部分，但是在策略模式中抽象由对象执行。

但是，如果我们阅读策略的定义:

定义一个算法族，封装每个算法，并创建它们可互换的。策略让算法独立变化使用它的客户端

没有定义如何应用策略。它也可以很容易地成为抽象上的接口，与linq - order等通用策略实现完全相同。

关于这个话题的另一个有趣的观点是:

http://game-engineering.blogspot.ch/2008/07/bridge-pattern-vs-strategy-pattern.html

本课程的主要部分:

当你想改变行为时，你说"策略"，但你没有这样做通过编写不同的对象，但通过引入类层次结构。你当你希望同时改变界面和功能时，请使用"Bridge"实现。在这两种情况下，都为a提供了灵活性改变的实现;在桥中，你也期待修改接口

这可能是主要的区别吗?由于实现者和抽象是松耦合的，所以我可以更改实现者的接口，而抽象不必关心。这听起来很合理，但这样抽象就不会改变了，因为它们之间是有某种联系的。这难道不会破坏所有其他原则，如信息隐藏和DRY吗?

我还看了很多例子，为了方便起见，我没有在这里添加，我找不到一个我不能改变以适应另一个模式的例子。可以通过接口属性，也可以通过参数。

我错过什么了吗?是否有人有"我想使用策略，但桥更适合"的现实例子，或者相反的例子?

编辑:为什么我要为这个主题(再次)证明一个自己的线程?首先，上述线程的可接受答案如下

据我所知，你在使用策略模式，当你抽象可以从外部源提供的行为(如。Config可以指定加载一些插件程序集)，然后使用桥接模式，当您使用相同的结构来创建您的代码更简洁一些。实际的代码看起来非常相似-您是只是应用模式的原因略有不同。

我已经在前面的解释中提供了，从外部来源抽象行为正是策略模式和桥接模式的定义。

也

，当你使用相同的结构时，你正在使用桥接模式让你的代码更整洁。

策略模式还使代码更简洁，因为它抽象了整个构建块，从而大大简化了代码。

我想任何读过整个主题的人都能看到，这个主题不仅仅是这两句话。

桥牌vs策略模式

我查看了原始设计模式书，看看作者是如何定义桥式模式的。他们在现实生活中的例子表明，当抽象和实现层次结构可以独立更改时(即可以为抽象引入新的子类;可以为实现引入新的子类)。他们的例子处理可以在不同的窗口系统中工作的窗口库。

在最初的示例中，作者使用了来自IBM的不同的窗口系统，但我认为当前比较好的类比应该是不同的Linux窗口管理器(GNOME, KDE等)。

那么，想象一个窗口抽象，以及GNOME和KDE的两个实现。现在假设你想要添加新的Window子类，transparentwwindow。透明窗口扩展窗口，所以GNOMEWindow和KDEWindow。但是您还必须为transparentwwindow: gnometransparentwwindow和kdetransparentwwindow提供实现。层次结构开始变得混乱。

想象一个新的窗口类型，或者新的窗口管理器——XFCE。为了避免复杂的层次结构，他们引入了桥接模式，并使两个层次结构分开(即透明窗口扩展窗口;

对我来说，棘手的部分似乎是定义实现的接口，因为抽象的层次结构将只需要使用该接口来定义它们的操作。

这里有一个我喜欢的桥模式的学习例子，我喜欢它是因为它没有使用人工类ConcreteImplementor1和ConcreteImplementor2。当谈到现实生活中的例子时，我相信我在Selenium WebDriver实现中看到了这种模式，但我现在不能100%确定。

在策略模式中，"父母"的活动对于特定操作的活动是恒定的，而"子"的活动则是恒定的。可能是不同的。然而，在桥接模式中，父节点和子节点的活动可以变化。

例如

public class Ticket {
    
    Date dateOfTravel;
    int distance;
    Vehicle vehicle;
    Seat  seat;
    
    public float getTotalFare(){
         //depends on 
               //Distance
               //Vehicle - whether Vehicle is AC or non-AC. 
               //Seat - based on the location of the Seat.
     
        //Fare = vehicleBaseFare*seatMultiplier*distance
    }
    
}

在上面，变化取决于父(距离)以及子(车辆和座位)。所以，这里车辆和座位都扮演桥梁的角色。

现在,这里

public class Vehicle {
   TrackingDevice device;
   public Coordinates getCoordinates(){
       return device.getCoordinates();
   }
}

这里，Parent的角色是常量，也就是说，什么都没有!所以，这是一个策略模式

相关文章：