3

本「Head first design patterns」のデコレータの章では、デコレータが具象型を処理し、問題を引き起こす場合の問題について説明しています。この章のいくつかの Q&A をコピーしています。

Q: 特定の具体的なコンポーネント (HouseBlend など) をテストして、割引を発行するなど、何かを実行するコードについて少し心配しています。HouseBlend をデコレータでラップすると、これは機能しなくなります。

A: その通りです。具体的なコンポーネントの型に依存するコードがある場合、デコレーターはそのコードを壊します。抽象コンポーネント タイプに対してのみコードを記述する限り、デコレータの使用はコードに対して透過的です。ただし、具体的なコンポーネントに対してコードを書き始めると、アプリケーションの設計とデコレータの使用を再考する必要があります。

「クライアント」コードが具象型と抽象型に対して書かれていることの意味について、誰かが簡単な例を挙げてもらえますか? そして、前者がどのようにデコレーターに問題を引き起こすのでしょうか?

この本のデコレータのサンプル テスト コードは次のようになります。

public class StarbuzzCoffee {
    public static void main(String args[]) {
        Beverage beverage2 = new DarkRoast();
        beverage2 = new Mocha(beverage2);
        beverage2 = new Mocha(beverage2);
        beverage2 = new Whip(beverage2);
        System.out.println(beverage2.getDescription()
            + “ $” + beverage2.cost());
        ...
    }
}

このテスト コード (クライアント コードでもあります) は、抽象型に対して記述されていますか?

ありがとう、

4

2 に答える 2

3

彼らは、たとえば、beverage2 の種類をチェックするコードについて話している

if (beverage2 instanceof DarkRoast) {
    <do_something>
}

ビバレッジ 2 をモカまたはホイップで装飾すると、もはやダークローストではありません。

編集:多くの場合、 の使用はinstanceof、OO を最大限に使用しない貧弱な設計を示していることにも言及する必要があります。これは、場合によっては役立つと述べています。

于 2012-09-28T06:11:00.723 に答える
0

抽象コンポーネント タイプに対してのみコードを記述する限り、デコレータの使用はコードに対して透過的です。

はい。そうあるべきです。

具体的なデコレータの実装に固有の新しい機能をデコレートするべきではありません。一度やると、デコレータパターンの目的が失われます。

デコレーター パターンは、インターフェイス自体を含む抽象的なデコレーター (コンポジションを使用) によりうまく機能します。さまざまなフレーバーのさまざまな組み合わせの数を減らすのに役立ちます。

同様のユースケースのためにDecoratorパターンを実装 しました。このドキュメントリンクを見てください

Decorator パターンを使用する場合

 Beverage beverage = new SugarDecorator(new LemonDecorator(new Tea("Assam Tea")));
 beverage.buildBeverage();

次の合計である 18 として出力が得られますTea (10) + Lemon (5) + Sugar (3)。

Cost of:Assam Tea+Lemon +Sugar :18

上記の例を機能させるにDecoratorは、ドキュメントのリンクで説明されているように、要約をいくつか変更する必要があります。抽象クラスの構成によりBeverage、Decorator複数のフレーバーを簡単に追加できます。

Concrete Decorator に基づいてビジネス ロジックを追加しないでください。Concrete Decorator のインテリジェンスをコードに組み込むと、動的な責任を個別に追加する柔軟性が失われます。

于 2016-08-04T15:32:27.493 に答える