的多個實現的多個實例，我需要設計一個自動售貨機分配各種飲料，如茶，咖啡。一個具體的類VS抽象類
我幾乎完成了設計，但有這一個，我不能夠採取的決定。
關於飲料類。
我應該做一個具體Drink類具有某些屬性和每喝做出新的實例，並設置相應的屬性。
實施例： -
Drink tea = new Drink();
Drink coffee = new Drink();
或另一種方法可以是我使一個抽象類飲料。
abstract class Drink{ }
，使茶葉和咖啡就像
class Tea extends Drink{ }
class Coffee extends Drink { }
什麼都該方法的利弊？
如果僅僅領域從一個實例到另一個不同，我建議你第一種方法，如果行爲（方法），也可以不同，我建議後者。
還有一點要考慮的是，如果你希望能夠增加新種類的飲料無需升級應用程序...
這取決於和方法的一個並不總是比其他方法更好。
每類飲品都有一個子類的好處是，您可以在適當的子類中實現特定於飲品類型的功能，而不必在Drink類中放置所有類型飲品的所有功能。但是否與您的應用程序相關取決於Drink的角色是什麼，以及您是否需要飲料類型特定的功能。
如果類Drink只是一個簡單的數據容器類，例如它包含幾個字段的飲料名稱等，並且不需要特定的邏輯來適用於不同種類的飲料，那麼第一種解決方案更簡單，你只需要一個類Drink。
你不必爲Drink任何通用的模型，你只需要保留的幾件事情的軌道，如
name（這飲料是什麼？）inventory（如何許多這些飲料仍然可用）（每單位）pricesales（的可能有一些（image？），但你並不需要你的飲料知道特定的屬性，在某些情況下，而不是在其他意義（例如，color爲red/white葡萄酒）。例如，您可以輕鬆地區分波光粼粼的和靜止的水，通過同一班級的兩個不同實例進行區分，事實上，Water班的班級太過分了，因爲它不會爲您的模型添加任何有趣的內容。
換句話說，建立與項目上下文相關的對象建模並抵制模擬所有可以想到但與您的特定領域無關的屬性和行爲的誘惑。
使用抽象方法。它提供了Code Reuse和Polymorphism的優勢。我相信你已經聽到了術語「Always program to the interface」。這是你應用它的機會。