数日前、私たちのチームは、柔軟なDB実装のデザインパターン（Oracle、MYSqlなど）について話し合っていました。
ブリッジパターンと抽象ファクトリパターンについて説明しました。
柔軟で実装が簡単で、クライアントが基盤となるDB実装が何であるかを知らないため、私はAbstractFactoryを支持しました。しかし、私の他のチームメイトは、AbstractFactoryよりもBridgeを好みました。彼らは、クラス階層が大きくなると、さらに柔軟で保守が容易になると述べています。
なぜAbstractFactoryを使用できないのか、まだ満足していません。さまざまなDB実装の両方のパターンを比較するための提案と優れたリファレンスを探しています。
これら2つは相互に排他的であるとは思いません。抽象ファクトリは、物事がどのように作成されるかについてです。物事が作成されるまで、ブリッジは起動しません。
Abstract Factoryは、Amazonを呼び出して何かを注文するようなものだと思います。アマゾンはそれを手に入れる方法や作る方法を知っています、そしてそれがどのように起こるかは私には関係ありません。
ブリッジは、アイテムが配置される「箱と梱包材の性質」に似ています。ベースオブジェクトを作成して組み合わせる必要があり、AbstractFactoryはそれを実現するための優れた方法です。
もし私が側に立つ必要があるとしたら、私はあなたの側に寄りかかる傾向があります。なぜなら、彼らが具体的な実装を可変にすることに非常に関心を持っているという事実と、それへの道が非常に遠回りであるという事実は、おそらく彼らが望んでいることを私に示唆しているからです。最終的に作成されたデータベースオブジェクトについて知るには、あまりにも多くのことがあります。誰かがそれをグローバルにアクセス可能にしたい場合、または実装者がグローバルオブジェクトから実装に手を伸ばして取得することを望んでいる場合でも、私は驚かないでしょう。
厳密に規制されたサービスレイヤーへのアクセスを維持する場合（たとえば、ビューがコントローラーレイヤーなどのサードパーティのリクエストのみを許可する場合）、サービスレイヤーの作成方法と実際の内容はそれほど重要ではありません。とにかくそれについて実際に知っているのは1つだけです。
前述のように、Abstract Factoryパターンはオブジェクトを作成するためのパターンであり、Bridgeは構造パターンであるため、それらの使用法は相互に排他的ではありません。
ブリッジを使用するか、一般化を使用する単純な戦略パターンを使用するかは、次の質問に帰着します。
実行時に戦略を切り替える必要がありますか？戦略ごとに複数の実装クラスを作成する必要がありますか？
これらの2つの質問のいずれかが「はい」の答えをもたらす場合、ブリッジパターンがあなたに利益をもたらす可能性があります。
次の質問に当てはまる場合は、AbstractFactoryが必要になる場合があります。
具体的なタイプを知らなくてもインスタンスを作成する必要がありますか？
すでに述べたように、AbstractFactoryは物を作成することです。実際、抽象ファクトリはBridgeパターンオブジェクトを作成できます。したがって、この2つは相互に排他的ではありません。
個人的には、Bridgeは多くのシナリオで非常に複雑であり、リポジトリパターンを使用する場合など、単純なファサードパターンの背後にあるものを抽象化することを好みます。
ただし、複数の実装タイプを中心に標準操作を定義する場合は、Bridgeの方が便利な場合があります。私の意見では、将来、別のバックエンドに交換できる抽象化を作成したいだけの場合は、過剰に設計されています。実行時に異なるバックエンドを使用する場合は、それが適切な場合があります。