我有一个非常基本的问题：

我们什么时候应该决定为特定的类使用接口或类？

例如：说我们有两个班，客户和医生。

在继承(类)中：我们可以将这两个类设置为从父类Person继承。

我们不能对接口做同样的事情吗？说我们有InterfacePerson，让客户和医生都实现这个接口？

因此，这导致了：我们什么时候决定使用一个对另一个，反之亦然？

• 阅读维基百科的文章

• 读一本书，然后再读一次有关OOP的章节

• 在您的示例中，Person应该是一个类，因为它包含了Doctor和Customer共同的实现细节。

• 接口没有(也不需要)实现细节——它们只表示实现它们的对象正在做什么。不是怎么回事。为什么这个有用？因为当你使用这个物体时，你不在乎它将如何工作。

让我们来看一个简单的例子——有一个接口EDOCX1，3(至少在Java中)。它表示它的实现者可以相互比较。所以你可以有两个班：

现在，您可以有一个通用的方法，它使用实现Comparable和调用comparable1.compareTo(comparable2)的任何对象集，因为您知道它们可以执行比较——它由它们的接口表示。

• 界面-描述行为
• 课堂-做行为

扩展另一个类的类继承该行为。另一方面，实现接口只是说它需要这样做，但是类仍然需要知道如何操作。

除了单一继承限制之外，使用接口的代码更容易重构和测试，例如在单元测试中为数据库访问对象提供模拟实现。

所以，真正的答案是，这取决于你的设计。

可能是您使用接口来描述行为，而抽象父类来实现子类可以继承的行为。或者子类是如此不同，以至于每个子类都以自己的方式实现接口。

接口用于强制某些方法/属性。简而言之，接口是一套规则。

类可用于继承/重写基本功能。

看一看

• 班级与C中的接口
• C：接口与类
• 抽象类与接口
• 接口(C参考)

在对象建模中，不应该为人员及其角色使用继承。一个应该用两个关联的对象来建模它们。也就是说，使用组合而不是继承。

因此，在某种程度上，在三个备选方案中，您讨论了两个错误的方案：继承和为参与方和角色建模的接口。

类是一组对象的模板。这些对象具有行为(通常)状态和特征。在行为方面，每个对象已经有了一个(隐式)接口：可以在外部调用的一组方法。

问题就变成了，为什么要创建一个命名接口，一个对象已经提供的接口的子集？

首先要记住，类可以实例化，接口不能。

其次，一个类只能扩展一个类。接口不受此限制，因此我们可以像这样拥有多个继承

foo是一个人。它也是人和哺乳动物；

唯一的问题是接口不能有变量或方法实现，因为类(或抽象类)可以。

一般来说，如果可以的话，我会说坚持使用接口并避免使用抽象类。

父类将具有所有子类通用的最小裸露属性。

但是，接口是一个契约，它告诉它的植入式如果不是抽象类，就提供它。

类和接口之间的一个重要区别是

类继承将给出两个公共子类之间的关系。

其中as接口实现提供了两个不常见类之间的关系。

简单地说，当涉及到代码/实现时使用类，当只是接口描述时使用接口。在引用代码中的对象时，更喜欢引用接口，因为这样可以更容易地替换实际的实现(或者添加更多不同的实现)。

是的，Docor和客户/患者都可能实施或扩展人员。

把接口看作一个契约。类可以提交到合同(实现接口)

假设你有一个有医生和病人子类的班级成员。然后，您可以使用患者实现的getSymptoms()方法进行接口治疗，并使用医生实现的方法cure(可治疗)进行接口治疗。最有可能的治疗方法(可治疗)在某个时候会调用getSymptoms()。

类建议继承基类的对象是此类的某种类型

如果您使用接口，它只显示您的类有一些接口描述的常见行为。

在C中，只能通过接口实现多重继承。基于U R业务需求，如果有需要您的类需要多个继承，那么使用interface-else-use-class。

此外，接口的所有成员都应在类中进行定义，即接口成员必须是实现成员。