5

私はこの記事を読んでいます：

http://www.codeproject.com/Articles/479635/UnderstandingplusandplusImplementingplusDecoratorp

このパターンを学校のプロジェクトに実装することを考えています。それは要件ではないので、私はそれを半ばすることができます。しかし、自分の知識や専門知識を広げる良い機会になると思いました。

学校のプロジェクトは次のとおりです。従業員が顧客の注文を入力するピザ注文アプリケーションを作成します。だからピザ、そしてそれはトッピングをいくつでも持つことができます。

上記の記事（およびHead First：Design Patternsの本の説明）は、私のアプリケーションと完全に一致しているようです。

これが私の問題です：これは良いパターンのようには見えません、そしてここに理由があります：

「ピザ屋」がメニューに新しいトッピングを追加するたびに、まったく新しいクラスを追加し、注文システムを再コンパイルして再配布する必要がありますか？

おそらく問題は、私がグーグルで検索したすべての例が、ある種の食べ物やトッピングを扱わなければならないということだと思います。

  1. このパターンの間違ったタイプの例を見つけているだけですか？
  2. このパターンが実装されるより良い例は何ですか？
  3. 食品業界はその1つであり、厄介なのは実装だけですか？
  4. これは、世の中に出回っているが実際の製品コードではほとんど使用されていないパターンの1つですか？
4

4 に答える 4

5

実際、Decoratorを使用すると、ソースコードを再コンパイルせずに動作を追加できます。ピザドメインでインターフェースを宣言IPizzaし、アプリケーションでこの抽象化を使用できます。次に、デコレータの場合は他の実装を持つ別のアセンブリを追加IPizzaし、依存性注入を使用してそれらの実装をアプリケーションに注入できます。したがって、アプリケーションもドメインも再コンパイルする必要はありません。

ところで、既存のクラスを変更するよりも、新しいクラスを追加する方が優れています。変更前に機能していたものをいつでも壊すことができます。そのため、単一責任原則が導入されました。

別のあなたの質問：

  1. いいえ、デコレータパターンの使用例を見つけています（特にHead Firstの本にあります）。また、IOStreamクラスとそのデコレータからインスピレーションを得てください。
  2. パターンは問題を解決するはずです。パターンの使い方が間違っているというよりも、どのパターンがターゲットになっているのかという問題がなければ。
  3. パターンは業界に固執しません。彼らはあなたのコードの問題に固執します（しばしばそれはコードの重複についてです）
  4. いいえ、それは良いパターンです。.Netのストリームについてもう一度考えてみてください。プロダクションコードですか？
于 2013-01-25T16:58:38.037 に答える
1

一般に、現実世界のアプリケーションでは、より抽象的なオブジェクトを扱います (つまり、ピザやコーヒーのようなものではありません :))

Decorator パターンの実際の例は、JavaBufferedReaderクラスです。FileReaderたとえば、追加機能を追加します。

利点は、実行時に動作を変更でき、多くの異なるオブジェクトを持つことに縛られないことです。

あなたの例では、4 つのオブジェクトがあるとします。

Pizza
Tomatoes
Cheese
Mushrooms

次に、4 つの材料を自由に組み合わせてピザを作ることができます。そうしないと、その動作を許可するために大量のクラスが必要になりますPizzaWithTomatoesAndCheese。PizzaWithTomatoesAndMushrooms

于 2013-01-25T16:56:37.940 に答える