design-patterns - ブリッジ パターンと依存性注入

Question

ブリッジ パターンと依存性注入の違いは何ですか?

どちらのパターンにも、別の抽象化を実装した抽象クラスがあります。以下に Bridge Pattern UML ダイアグラムがあります。

Answer 1

AFAIK Dependency Injection は設計パターンではなく、 SOLID 原則で定義された設計ガイドラインです。

そのため、ブリッジ パターン は依存性注入を使用して、コンストラクターに が注入され、API の具体的な実装からDrawingAPIを分離する必要なポリモーフィック動作を実現します。Shape

ウィキペディアの Bridge Pattern の例からのスニペット

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

Bridge Pattern -デザインパターン

依存性注入 -設計ガイドラインまたは原則

Answer 2

いくつかのメカニズムを介して依存性注入を行うことができます。Bridge メカニズムはその 1 つにすぎません。単純なインターフェースの実装は別です。クラス織りやその他の動的なトリックは、さらに別のものです。

依存性注入は開発/設計手法ですが、いくつかの方法で実装できるため、パターンではありません。

これについてもう少し考えてみると、一連のアーキテクチャの問題 (テスト容易性、構成可能性、モジュール性など) に対処する一般的な方法であるという意味で、依存性注入をソフトウェア アーキテクチャ パターン (ただし、設計パターンではない) と見なすことができます。

言い換えれば、依存性注入は事実上パターンと見なすことができますが、異なるレベル、つまり設計ではなくアーキテクチャと見なすことができます。

Answer 3

多くのデザイン パターンには、同様の UML ダイアグラムがあります。

Bridge パターンは、Dependency Injection とはまったく異なります。

依存関係の挿入- 実行時またはコンパイル時にコードに依存関係を簡単に挿入 (および交換) する方法。

ブリッジ パターン- 異なるシステム間で追加のインターフェイスを持つ方法。ブリッジは、コードと他のシステム間の通信レイヤーです。たとえば、Java で最もよく使用される 2 つのブリッジ パターン実装は、JDBC (ドライバー ブリッジを介してデータベースと通信する) と Swing (ブリッジを使用してオペレーティング システムの UI と通信する) です。これにより、システムへの通信レイヤーに影響を与えたり変更したりすることなく、他のシステムを交換または変更できます。

編集：ブリッジは、ブリッジの両側が他方に影響を与えることなく独立して進化および変更できることを言及するのを忘れていました. これは、ブリッジが両側を互いに分離しているためです。