ブリッジ/ブリッジデザインパターンの誤った使用

先史時代



Bridgeのデザインパターンに関するこの記事を読みました。 悲しいかな、それは非常に頻繁に誤って使用されます。 さらに、 オブジェクト指向設計のトリックという本を開きました。 デザインパターン 。 それが判明しました-そして、著者は非常に漠然とその存在の理由とそれを使用する理由を宣言します。 そのため、以下では、これを使用する方法と理由を説明します。



更新する



これは、正確に解釈できない表面的な記事です。 しかし、その尊厳は、それが短く、問題につながることです。 専門家にとっては、より深い質問を提起することができ、若い開発者にとっては、いくつかの誤解があります。 私は実際にThe Gang of Fourと議論していますが、私はファウラーとリファクタリングに対する彼のアプローチに完全に同意します（そして彼らは自分たちの間で矛盾を持っています）-しかし、私が議論する人のように。



専門家向けの拡張記事を準備していますが、若い開発者が設計パターンを機械的に学習するのに役立つ場合があります。 彼らはいつ使うべきかをよく理解していませんが、専門家がパターンから優先されるべきであるという意味で議論することは重要だと思います。 この拡張された記事で、「ブリッジ」パターンを取り除く必要がある理由を説明し、限られた意味でメディエーターパターンを使用することを期待します。



この記事には既に「Bridge」パターン（双方向ブリッジ）またはMVC->「Business Entity-Visualization-Controller」の正しい使用方法のブランチがあります 。 視覚化とビジネスロジックを分離するときに、ブリッジ/メディエーターを組み合わせて使用​​できることが示されていますが、これがこれらのテンプレートのほとんど唯一の領域です。 純粋なビジネスロジックと低レベル/システムタスクでは、これらのパターンは避ける必要があります。



しかし、公開することはできません。カルマはありませんが、理解しているように、入力するまで他の選択肢はありません。 だからあなたは読みたい、あなたは何をすべきか知っている:)



実際にブリッジの設計パターンは何ですか



オブジェクト指向プログラミングを知っているなら、私はすべての責任をもって、パターンについて知ることは絶対に必要ではないと宣言します。 パターンは単なるプライベートであり、OOPの原則に基づいた最も成功したソリューションとは限りません。



「ブリッジ」パターンとは何か、この難解な用語の背後にあるものを見てみましょう。 それは、継承と集約の組み合わせにすぎません。 悲しいかな、彼らはしばしば集約が何であるかを知らない。 簡単に言えば、これは、あるオブジェクトが別のオブジェクトに含まれる場合です。





ブリッジパターンを使用する本当の理由



この本の著者はこの目標を宣言しています：「抽象化をその実装から分離すること」。



しかし、これは完全に真実ではありません。 原則として、それは有害ですらあります。 これはOOPに反しています。 実装は、抽象化で宣言されているものと完全に一貫している必要があります。 それ以外の場合、価格は一般に宣言を販売から分離する価値があります。 クラス宣言を見て、クラスの実装がそれに対応していないことが判明した場合、最も重要なものを失いました- 多態性を失いました。 その後、実装に慣れることを余儀なくされ、抽象化/仕様のみを知るだけでは不十分です。



しかし、ポイントは多少異なります。 そして、例によって明らかになります。 継承が適用される例が示されています。 しかし、継承は単純ではありませんが、2つの異なる基準に従っています。 たとえば、「Windows」はさまざまなオペレーティングシステム（XWindow、PMWindow、...）、およびさまざまな目的（アイコン用ウィンドウ（IconWindow）、メッセージ用ウィンドウ（MessageWindow）など）に分類できます。



次に、最終ウィンドウには、ある階層の関数と別の階層の関数が含まれている必要があります。 つまり 目的とオペレーティングシステムに特化する。 次に、当然ながら、継承装置に問題が生じ、これらの階層の乗算としてクラスを作成する必要があることがわかります。 XIconWindow、PMIconWindow、XMessageWindow、PMMessageWindow。 もちろん、これは別のOOP原則-単純なエンティティの単なる組み合わせである余分なエンティティの作成-にすでに違反しています。



これは、多重継承を使用する典型的な例であることに注意してください。 つまり XIconWindowは、IconWindowおよびXWindowの子孫です。 しかし、最近の傾向により、複数の継承が不適切なPLOとして特定されています。 ここでは説明しませんが、実際には理論的には多重継承は不要であり、主題領域の誤解があります。



そのため、パターンの作成者は別の方法を提供します。 彼らは、階層の1つが物理的な実装に責任があるという特定を見ました。 どのOSのためにそれが行われます。 そして、もちろん、これは非表示にする必要があります。 しかし、これは特殊性にすぎませんが、実際には他の階層が存在する場合があります。 たとえば、ウィンドウは、シングルウィンドウ（SDI）またはマルチウィンドウ（MDI）の原理によって異なる場合があります。 そして、何、階層のもう一つの乗算？



そしてもちろんそうではありません。 オブジェクトのこれらの階層がプロパティであるという理解を保存します。 そして、プロパティを実装する方法は？ 指定されたオブジェクトにそれらを含めて、そうです。 つまり 集約を適用します。



これが「ブリッジ」パターンを作るものです。 しかし、本質的にこのパターンは、OOPのより一般的な原則の不器用な説明です。



しかし、どうすればより正確に議論するのでしょうか？



とても簡単です。 一般的なプライベートの関係があります—継承を適用​​します;部分全体の関係があります—集約を使用します。 しかし、これはそれほど明白ではない場合があり、一般的なプライベートの関係があるように思われますが、2つ、3つの異なる基準（上記）に従っています。 しかし、このような推論は混乱を招くだけであり、それに応じてプログラムのアーキテクチャを悪化させることを覚えています。 それから、どの基準がより重要でどれがより低いかを決定しなければなりません。 それらを階層に配置し、一方を他方にネストします。 「ブリッジ」パターンの作成者は、オペレーティングシステムへの特性の実装は、ウィンドウの目的よりも重要ではないと考えています。 しかし、これは特別な場合にすぎません。 他の基準が存在する場合があり、そのたびに何が一部で何が全体かを決定する必要があります。



さらに、これは多くの場合、部品がすでに実装されており、追加の製品が登場したときに決定する必要があります。 次に、リファクタリングを処理し、継承を集約に変換する必要があります。 したがって、継承はクラス間でより厳しい束を作成することを覚えておく必要があります。 そして常に、機会があれば、集約を好む方が良いです。 これにより、クラス仕様と異なるクラス間の関係をより明確に定式化できます。 継承は非常に慎重に使用する必要があります。 それ以外の場合、後で集約に再作成する必要があります。これは多くの場合、それほど単純ではありません。 継承は、遺伝的分類の基準を明確に区別できない場合にのみ使用する必要があります。 このクラスがより抽象的なクラスの亜種であり、基準ではなく一般的なものであることがわかっている場合。



しかし、「アラーム」の実装と「アラーム」の抽象化を決して区別しないでください。 これは、PLOの誤解を示しているだけです。 したがって、このメモを作成する理由となった記事では、目覚まし時計の実装として宣言されたエンティティが「ブリッジ」として提示されています。 興味深いことに、しかし、いわゆる アラームの抽象化-実装ではありませんか？



実際には、メッセージの呼び出しと送信という2つの機能がそこに作成されています。 そして、これはさまざまな方法で行うことができます。 明らかに、これらの機能の組み合わせは人為的です、なぜなら それらのさまざまな組み合わせが可能です。 したがって、私たちが持っている目覚まし時計の抽象化は、擬似実装ではなく、2つのエンティティ-メッセージマネージャーの抽象化とメロディプレーヤーのマネージャーを使用します。 そして、コンストラクターの助けを借りた具体的なクラスは、メッセージのタイプとメロディーの演奏方法を定義します。



結論は1つだけです。設計パターン、特にBridgeで議論されたもの、特に重要な原則を理解していないものなど、よく考えられていないものは、プログラマーとそのプログラムを干渉、混乱させるだけです。



更新しました。 追加の説明。



この記事の目的は、読者がブリッジとは何かに精通していることです。 「ブリッジ」パターンを次のものと混同しないようにお願いします。

1.単純な集約-エンジンがマシンに集約される場合（使用可能なマシンとエンジンの種類に関係なく）

2.インターフェイスの使用は最初のものと似ていますが、唯一の違いは抽象クラスの代わりにEngine、Engineなどのインターフェイスが使用されることです。



これはすべて、「ブリッジ」パターンの必要性に達しません（あまりにも細かく、つまり、「ブリッジ」パターンは、より複雑なケースで著者が考えたように使用されます）。 ここでも、「ブリッジ」を適用すると、すべての実装が強調表示される、つまり、 別のクラスのすべての低レベル関数、つまり マシンのエンジンの機能ではなく、MachineRealizationのマシン自体の低レベルの機能（プライベート）です。



「ブリッジ」とは別のものを意味する場合、この記事はあなたに向いていません。 あなたはすべてを正しくしている、または単に「橋」が必要な状況にまだ遭遇していない-そして非常によく、 彼は本当に必要ではありません。



別の「ブリッジ」-多重継承を使用して実装できるので、自分自身と例を確認してください。 したがって、たとえば、最初の2つのタイプ-「単純な集約」と「インターフェースの使用」は、明らかに多重継承を保持する場所がないことを示しています。つまり、「ブリッジ」も必要ないということです。



それとも、もっと簡単です-機械からエンジンを継承することはあなたに起こりますか？ または、手紙からの手紙の送信者を言う？ または、データベースの抽象化またはWindowからのファイルクラスですか？



ただし、「ブリッジ」パターンの使用例では、これが初期位置であり、「ブリッジ」を使用して修正する必要があります。 しかし、そのような形式の継承が可能かどうかを考えてください。 最初の状況が異なっていて、何か他のものについてブリッジを使用したと思うのはなぜですか？



「橋」の話は、1つのセクションではなく、継承があるときに始まります。 つまり 乗用車とトラックが機械から継承されるだけでは不十分です。 機械から継承する別の欲求がシステムに必要です-観光用の機械、輸送用の機械...そして、旅行用の旅客機、輸送用の旅客機の組み合わせクラスも必要です...そして、そのような恐怖が現れたときのみ-あなたは「ブリッジ」を使用することを余儀なくされます必要な場合でも、ブリッジを適用しないでください）。 しかし、パターンの作者が説明するようにではなく、この記事で説明するように、私は本当に望んでいます。



upd2。 もう1つの誤解を取り除いてみましょう。



もちろん、「ブリッジ」を実装するために、抽象クラスの集合が使用されるか、インターフェースが使用されるか、他の何かが使用されます。 これはそれについてではありません。 「ブリッジ」パターンを使用する場合と使用しない場合の理由についてです。 使用する動機についてです。 著者によって記述された特定の動機があり、この記事の一部である場合、それは必要です。 しかし、これは反対を意味するものではなく、インターフェイスまたは抽象クラスを使用した場所はどこでも、ブリッジになります。 したがって、機械とエンジンを使用した上記の例は、純粋に意味論的には「ブリッジ」パターンではありませんが、構文的には同じインターフェースを見ることができますが、「ブリッジ」ではありません。

これはほんの一面です。 記事のもう1つの主要な記事で、著者が「ブリッジ」の使用を推奨する状況に実際に遭遇した場合、これはお勧めしません。これは有害であり、他の方法もあります。 しかし、パターンの作成者として議論することはお勧めしません-抽象化から実装を選択します。



upd3。 コメントに問題があります。 ここで2つの質問に答えます。



1. TheShockの多重継承について。 これは、コンパイラがこれを行ったかどうかを確認できないため、エラーが発生する可能性があるためです。



2.コルウィンの興味深いパズル。 オプションの1つ。 最初のステップは、WinとOs2の相続人を含む階層OSを作成することです。 ImageMap LoadFromFile（）およびPaint（BigImage argImage）メソッドを使用してImageProcessingインターフェイスを作成します。 WinとOs2は、それぞれ独自の方法でImageProcessingを実装します。 準備された階層にリファクタリングすることでBigImageImpを取り除きます。 BigImageでは、ImageProcessing imインターフェースを集約します。 BigImageの後継では、Loadメソッドは最初にim.LoadFromFile（）を呼び出し、Showは最後にim.Paint（this）を呼び出します。



それは橋でもあると言えますか？ しかし、少なくとも、セマンティクスは桁違いに明確になりました。



オプション2（最初から作成され、並行して実行することもできます。つまり、最初のオプションをロボットのままにします）。 クライアントにOSを使用させることができます。 OS.Paint（argBigImage）を呼び出します。 これを行うには、OSがBigImageメソッドを呼び出すように、他の方法が必要です。 つまり ペイントはargImageMap = LoadFromFile（）を呼び出し、次にargBigImage.Load（argImageMap）を呼び出します-たとえば、BmpBigImageは独自の特異性を画像の継承者にします。 次に、OSはargBigImage.PrepareForShow（）を呼び出し（これにより、イメージのShowメソッドの意味が明確になります。実際には、それは自分自身を表示できないことが判明しているため）、OSは実際に表示されます。 そして、橋はすでに絶対にありません。 また、最初のソリューションを削除すると、ImageProcessingインターフェースを取り除くことができますが、これはオプションです。 ちなみに、2番目のオプションは最初のオプションを正しいセマンティクスに分解することによってのみ発明でき、ブリッジのフレームワーク内で考えることは実際にはオプションではなく、解決策は悪いことに注意してください。