几天前，我们的团队正在讨论灵活数据库实现的设计模式——Oracle、MYSql 等。
我们讨论了桥接模式和抽象工厂模式。
我赞成抽象工厂，因为它灵活、易于实现，而且客户端不知道底层的数据库实现是什么。但是我的其他队友更喜欢 Bridge 而不是 Abstract Factory。他们提到，当类层次结构全部增长时，它更加灵活且易于维护。
我仍然不满意为什么我们不能使用抽象工厂，我正在寻找您的建议和良好的参考资料，我可以在其中比较两种模式和不同的数据库实现。
问问题
648 次
3 回答
1
如前所述，AbstractFactory 是关于创造事物的。实际上，抽象工厂可以创建桥模式对象。所以两者并不相互排斥。
就个人而言，我发现 Bridge 在很多场景中过于复杂，并且更喜欢将事物抽象到简单的外观模式之后，例如在使用存储库模式时。
但是，如果您打算围绕多种实现类型定义标准操作，Bridge 可能会更有用。在我看来，如果您只是想创建一个允许您在未来某个时间切换到不同后端的抽象，那么这就是过度设计。如果您要在运行时使用不同的后端，那么它可能是合适的。
于 2012-09-22T21:02:34.863 回答
1
我不认为这两者是相互排斥的。抽象工厂是关于如何创建事物的。直到创建了东西之后，Bridge 才会启动。
我认为抽象工厂就像打电话给亚马逊并订购一些东西。亚马逊知道如何获得或制造那个东西，我并不关心它是如何发生的。
Bridge 更像是“盒子和包装材料的性质是什么”，物品将被放入其中。基础对象需要制作并装配在一起，而 Abstract Factory 是实现这一目标的好方法。
如果我不得不选边站，我会更倾向于站在你这边，因为他们非常关心使具体实现可变并且实现它的路径如此迂回这一事实向我表明，他们可能想要一旦最终创建了数据库对象，需要了解的事情太多了。如果有人希望它是全局可访问的，或者他们希望实现者伸出手并从全局对象中获取一个实现，我不会感到惊讶。
如果您对服务层的访问进行严格监管（例如，只允许 View 向某些第三方发出请求，例如 Controller 层），那么如何创建服务层以及它实际上是什么就没有那么重要了——无论如何，实际上只有一件事知道。
于 2012-09-22T18:03:22.933 回答
1
正如已经提到的，抽象工厂模式是一种创建对象的模式，而桥是一种结构模式，因此它们的使用并不相互排斥。
是使用桥接模式还是使用泛化的简单策略模式归结为以下问题：
运行时需要切换策略吗？是否会被迫为每个策略创建多个实现类？
如果这两个问题中的任何一个得到肯定的答案，那么桥接模式很可能会使您受益。
如果以下问题为真，那么您可能需要一个抽象工厂。
您是否需要在不知道具体类型的情况下创建实例？
于 2012-09-22T18:14:36.297 回答