的多个实现的多个实例，我需要设计一个自动售货机分配各种饮料，如茶，咖啡。一个具体的类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”。这是你应用它的机会。