紅茶やコーヒーのような様々な飲み物を調達する自動販売機を設計する必要があります。コンクリートクラスの複数のインスタンスと抽象クラスの複数の実装の比較
私はデザインがほとんど完成していますが、私が取ることができないこの1つの決定があります。
ドリンクのクラスについて
具体的にはDrinkクラスを特定の属性に設定する必要があります。すべての飲み物について、新しいインスタンスを作成し、それに応じて属性を設定します。
例： -
Drink tea = new Drink();
Drink coffee = new Drink();
または別のアプローチは、私は、抽象ドリンククラスを作ることをすることができます。
abstract class Drink{ }
と
class Tea extends Drink{ }
class Coffee extends Drink { }
のようにお茶やコーヒーを作る両方のアプローチの長所と短所は何ですか？
フィールドだけがインスタンスごとに異なる場合は、最初のアプローチをお勧めします。動作（メソッド）も異なる場合は後者をお勧めします。あなたがアプリケーションをアップグレードせず飲み物の新しい種類を追加できるようにしたい場合は、考慮すべき
もう一つのポイントは、それが依存...
で、アプローチの一つは、常に他のアプローチよりも良いではありません。
ドリンクの種類ごとにサブクラスを持つ利点は、Drinkクラスのすべての種類の飲み物にすべての機能を追加する代わりに、適切なサブクラスのドリンクの種類に固有の機能を実装できることです。しかし、これがあなたのアプリケーションに関係しているかどうかは、Drinkの役割が正確であるかどうか、飲み物特有の機能が必要かどうかによって異なります。
クラスDrinkが単純なデータコンテナクラスの場合、たとえば、飲み物の名前などのフィールドがいくつかあり、さまざまな種類の飲料に特定のロジックが必要ない場合、最初の解決方法は簡単です1つのクラスDrinkだけが必要です。
あなたは、あなただけな
nameとしていくつかのトラック維持する必要があり、任意の一般的な目的でDrinkをモデル化する必要はありません（これで飲み物を？）inventory（方法これらの飲料の多くは）利用可能なままである（）単位pricesales（日付によって販売されている単位）あり（？image）もう少しかもしれませんが、あなたには、いくつかのケースではなく、他に意味をなす特定の性質を知るためにあなたの飲み物を必要としない（（そのように選択された飲み物を知るために）例えば、red/whiteワインについてはcolor）。たとえば、同じクラスの2つの異なるインスタンスを持つことで、きらきらとした水を簡単に区別することができます。実際にはWaterクラスを持つことは、あなたのモデルに何も面白くないので、過度の殺害になります。
つまり、プロジェクトのコンテキストに関連してオブジェクトをモデル化し、考えられるすべてのプロパティやビヘイビアをモデリングする誘惑に抵抗しますが、特定のドメインとは関係がありません。
抽象的なアプローチに進みます。それはCode ReuseとPolymorphismの利点を提供します。そして、あなたが "Always program to the interface"という言葉を聞いたと確信しています。これを適用するチャンスです。