桥模式与依赖注入

Question

Bridge Pattern和Dependency Injection之间有什么区别？

对于这两种模式，我们有一个抽象类，其中包含另一个抽象的实现。下面是Bridge Pattern UML图。

Answer 1

AFAIK依赖注入不是设计模式，而是SOLID principles中定义的设计指南。

所以 Bridge模式 使用 依赖注入来实现所需的多态行为，其中DrawingAPI被注入构造函数将Shape与API的具体实现分离。

Bridge Pattern of Wikipedia

示例中的代码段

protected Shape(DrawingAPI drawingAPI){
      this.drawingAPI = drawingAPI;
}

桥接模式 - 设计模式

依赖注入 - 设计指南或原则

Answer 2

您可以通过多种机制进行依赖注入。 Bridge机制只是其中之一。简单的接口实现是另一个。类编织和其他动态技巧又是另一种。

依赖注入是一种开发/设计技术，但不是模式，因为它可以通过多种方式实现。

更多地考虑这一点，您可以将依赖注入视为软件架构模式（但仍然不是设计模式），因为它是解决一系列架构问题（可测试性，可配置性，模块性，等）。

换句话说，依赖注入可以有效地被视为模式，但在不同的层面：架构，而不是设计。

Answer 3

许多设计模式都有类似的UML图。

Bridge Pattern与依赖注入完全不同。

Dependency Injection - 一种在运行时或编译时在代码中轻松插入（和交换）依赖关系的方法。

Bridge Pattern - 在不同系统之间建立额外接口的方法。 Bridge是代码与其他系统之间的通信层。例如，Java中两个最常用的Bridge Pattern实现是JDBC（通过Driver Bridge与数据库通信）和Swing（使用Bridge与操作系统的UI进行通信）。这样可以换出或更改其他系统，而不会影响或更改系统的通信层。

编辑：忘记提到桥梁也允许桥梁上的双方独立进化和变化而不影响另一侧。这是因为Bridge将两边隔离开来。

Answer 4

Bridge Pattern使用 Dependency Inversion 使桥接器工作，即Abstraction基类/接口依赖于Implementor接口。

依赖注入是依赖性反转原则中最常用的实现。

Answer 5

模式书主要使用类似的实现，例如。如果不是子类对象，则它将另一个对象传递给它。所以最后我意识到模式书与您如何编写实现代码无关。您使用类还是依赖注入？

该模式更多地是关于上下文或仅仅是一个故事，这是您设计此类架构以交付产品的原因。尽管实现的方式可能因模式而异，但在这里模式的诞生及其内在思想更为重要。

简而言之，如果您要将对象传递给类的构造函数，那实际上并不意味着您是否在使用任何模式。但是，如果该过程是出于特定目的而设计的，那么您可能会在模式书中找到一个名称而感到惊讶。

从Wiki

在软件工程中，软件设计模式是在软件设计中给定上下文中对常见问题的通用可重用解决方案。它不是可以直接转换为源代码或机器代码的最终设计。相反，它是如何解决可在许多不同情况下使用的问题的描述或模板。设计模式是形式化的最佳实践，程序员可以在设计应用程序或系统时用来解决常见问题。