🛠BridgeパターンとIoC,DIとの違い
Bridgeパターンは「構造的な設計問題」に対する解決策を提供し、DIは「依存関係とその管理」に関する問題を解決します
依存性注入(DI: Dependency Injection)はデザインパターンではなく、SOLIDの原則で定義されている設計指針である。
つまり、BridgeパターンはDrawingAPIをコンストラクタに注入してShapeをAPIの具体的な実装から切り離し、必要なポリモーフィックな振る舞いを実現するために依存性注入を使用しているのだ。
Bridgeパターン: Bridgeパターンは、「構造」デザインパターンの一つで、抽象化とその実装を別々に進化させることができるように設計します。これは、インターフェース（抽象化）と実装の間に「橋」を作ることで、これらが互いに独立して変更や拡張を行うことができるようにするためです。
DI (Dependency Injection): DIは、ソフトウェアの「依存関係」を管理するためのテクニックです。具体的には、あるオブジェクトが他のオブジェクトに依存している場合、その依存関係を直接コードに書くのではなく、外部から注入（提供）することで、ソフトウェアの結合度を下げることを目指します。これにより、コードのテストや再利用が容易になります。
Inversion of Control (IoC) 制御の逆転 は、オブジェクト指向プログラミングの設計原則の一つで、プログラムのフローやオブジェクトの制御を主プログラムから外部のフレームワークやサービスに移譲するというアイディアを表しています。この原則により、モジュール間の結合度を低減し、拡張性やテスト性を向上させることができます。
IoCの一般的な実装方法として以下のものがあります：
Dependency Injection (DI): これは最も一般的なIoCの形式で、オブジェクトが依存関係を自身で作成するのではなく、外部から（コンストラクタやメソッド、プロパティを通じて）注入される方法です。
Service Locator Pattern: このパターンでは、サービスやオブジェクトを中央のレジストリに登録し、必要に応じてそれを要求します。
Factory Pattern: オブジェクトが自分自身を生成するのではなく、専用のファクトリオブジェクトを介して生成されるパターンです。
Template Method Pattern: このパターンでは、アルゴリズムの構造をスーパークラスに持たせ、実際の実装をサブクラスに委譲します。
Strategy Pattern: このパターンでは、アルゴリズムの家族を定義し、それぞれをカプセル化して交換可能にします。アルゴリズムを使用するクライアントは変更されずに、アルゴリズム自体を交換できます。
このように、IoCは様々なデザインパターンを通じて実現できますが、その核心にあるのは「制御の逆転」、つまりプログラムの主導権を個々のオブジェクトから外部のエンティティに移譲することです。
いいなと思ったら応援しよう！
