桥接模式和依赖注入有什么区别?
对于这两种模式,我们都有一个抽象类,实现了另一个抽象。下面是桥接模式 UML 图。
您可以通过多种机制进行依赖注入。桥接机制只是其中之一。简单的接口实现是另一个。类编织和其他动态技巧又是另一个。
依赖注入是一种开发/设计技术,但不是一种模式,因为它可以通过多种方式实现。
多想一下,您可以将依赖注入视为一种软件架构模式(但仍然不是设计模式),因为它是解决一系列架构问题(可测试性、可配置性、模块化等)的常用方法。
换句话说,依赖注入可以有效地被认为是一种模式,但在不同的层次上:架构,而不是设计。
许多设计模式都有类似的 UML 图。
桥接模式与依赖注入完全不同。
依赖注入- 一种在运行时或编译时轻松地在代码中插入(和交换)依赖项的方法。
桥接模式- 一种在不同系统之间建立额外接口的方法。Bridge 是您的代码和其他系统之间的通信层。例如,Java 中最常用的两种桥接模式实现是 JDBC(通过 Driver Bridge 与数据库通信)和 Swing(使用 Bridge 与操作系统的 UI 通信)。这可以让其他系统被换出或更改,而不会影响或更改您系统的通信层。
编辑:忘了提到桥还允许桥上的双方独立发展和改变而不影响对方。这是因为桥将双方相互隔离。
桥接模式使用依赖倒置来使桥接工作,即抽象基类/接口依赖于实现接口。
依赖注入是依赖倒置原则最常用的实现。
模式书大多使用类似的实现,例如。如果它不是子类对象,那么它会将另一个对象传递给它。所以最后我意识到模式书不是关于你如何编写实现代码,例如。你使用类或依赖注入?
该模式更多地是关于一个上下文,或者只是一个故事,为什么要设计这样的模式来交付产品。尽管不同模式的实现可能相似,但模式的诞生及其内在思想在这里更为重要。
简而言之,如果您将一个对象传递给一个类的构造函数,这并不意味着您是否使用了任何模式。但是,如果该过程是为某种目的而设计的,那么您可能会惊讶于您可能会在模式书中找到一个名称。
来自维基,
在软件工程中,软件设计模式是针对软件设计中给定上下文中常见问题的通用、可重用解决方案。它不是可以直接转换为源代码或机器代码的完成设计。相反,它是关于如何解决可在许多不同情况下使用的问题的描述或模板。设计模式是程序员在设计应用程序或系统时可以用来解决常见问题的形式化最佳实践。