2

以下のクラス ダイアグラムでは、Bridge デザイン パターンを使用して単純なドキュメント作成アプリケーションを実装しようとしました。具体的な「DocMaker」はドキュメントのレイアウトを担当しますが、それぞれが「IFileFormat」を受け入れて各ドキュメントを異なる形式に生成します

私の問題は、ドキュメントが PDF の場合、ドキュメントを特別な方法で変更できるようにしたいということです。

DocMakerLayoutA であろうと DocMakerLayoutB であろうと、ドキュメント作成の最後にこの特別な PDF 機能を実行したいのですが、すべてがインターフェイスによって制御されているため、その場所が見つからないようです。

「IDocMaker」に「DoSomethingSpecialForPDF」という関数を追加すれば動きますが、「FileFormarBMP」クラスについては何もしないようにしなければなりません。それはちょうど悪い設計のようです。

このことを最初から間違って設計したのでしょうか、それともこの構造でこれを行う方法はありますか?

Bridge 設計パターンを使用したクラス図の例

4

1 に答える 1

1

Bridge パターンは、抽象化と実装を分離する必要がある場合に適しています。あなたの場合、ファイルの作成を抽象的に見る必要があるため、Layout具体的なFileプロパティを認識してはなりません。そのため、ブリッジ パターンを使用する場合、特別な実装に対して特別な動作を想定することはできません。

あなたの場合、Fileドキュメントの作成後にいずれかの機能があると想定できるため、doAfter()メソッドを追加しIFileFormatて、2 つの具体的な と に実装PDFできますBMP。の場合はを呼び出しPDF、の場合は何もしません。doAfter()doSomthingSpecialForPdfBMP

デザインが悪いと思われるかもしれませんが(笑)、実はブリッジパターンのメリット(2面独立バリエーション)があるんです。

しかし、重要な点の 1 つは、この質問に対する答えです。特別な PDF 機能の責任者は誰ですか? または、実際に関連する特別な機能は誰ですか? FileまたはLayout？

于 2014-05-21T07:13:01.183 に答える