具体类的多个实例与抽象类的多个实现

Question

我需要设计一台自动售货机，可以分配各种饮料，如茶和咖啡。

我差不多完成了设计，但是有一个我无法做出的决定。

关于饮料课程。

我应该制作具有某些属性的具体Drink类，并为每个饮料创建一个新实例并相应地设置属性。

示例： -

Drink tea = new Drink();
Drink coffee = new Drink();

或另一种方法是我制作一个抽象的饮料类。

abstract class Drink{ }

制作茶和咖啡

class Tea extends Drink{ }
class Coffee extends Drink { }

这两种方法的优点和缺点是什么？

Answer 1

这取决于，其中一种方法并不总是优于其他方法。

每种类型饮料具有子类的一个优点是，您可以在适当的子类中实现特定于饮品类型的功能，而不必在Drink中为所有类型的饮料提供所有功能类。但这是否与您的应用程序相关取决于Drink的确切作用，以及您是否需要饮料类型特定功能。

如果类Drink只是一个简单的数据容器类，例如它包含饮料名称等的几个字段，并且您不需要针对不同种类饮料的特定逻辑，那么第一个解决方案更简单，您只需要一个类Drink。

Answer 2

使用抽象方法。它提供Code Reuse和Polymorphism的优势。我相信你已经听过“＆{34; Always program to the interface＆＃34;这个词。这是你应用它的机会。

Answer 3

如果只有一个实例的字段不同，我建议你采用第一种方法，如果行为（方法）也不同，我会推荐后者。

要考虑的另一点是，如果您希望能够在不升级应用程序的情况下添加新种类的饮料......

Answer 4

您不必为任何通用目的建模Drink，您只需跟踪一些内容，例如

• name（这是什么饮料？）
• inventory（这些饮料中有多少可供选择）
• price（每单位）
• sales（按日期销售的单位注册表）
• code（所以要知道选择了哪种饮料）

可能还有更多（image？），但您不需要饮料来了解在某些情况下有意义的特定属性，而不是其他情况（例如，color代表{red/white 1}}酒）。例如，您可以通过使用同一类的两个不同实例来轻松区分闪闪发光和静水，实际上具有Water类会过度使用，因为它不会为您的模型添加任何有趣的内容。

换句话说，根据项目的上下文对对象进行建模，并抵制对您可以想到但在特定域中无关的所有属性和行为进行建模的诱惑。