我应该在Doctrine模型中使用抽象类还是接口？

Question

在Doctrine中，假设我想要实现不同类型的交通工具。也许是汽车、飞机、自行车等等...所有这些交通工具都有许多不同的属性，但也有一些非常普遍的东西，比如它们都是由某种材料制成的。

所以如果我想获取这种材料...应该实现一个抽象类Vehicle，其中包含一个属性material并实现getter/setter，还是应该定义一个接口IVehicle，并在其中定义getter/setter以确保有一个真正用于获取和设置材料的方法？或者甚至同时使用这两个？

使用接口感觉很“专业”...但在接口中定义getter/setter感觉不对，所以我的个人感觉是：

不使用接口，只使用抽象类。

但是抽象类的方法是否受到滥用的保护？例如，在另一个地方，我肯定希望从getMaterial函数返回一个Material类型...抽象类方法是否也能安全地防止返回完全意外的东西（像接口一样）？

因此，如果我将此交通工具扩展为另一个具体类，开发人员不应该能够返回意外的东西，但也应该能够在需要时更改特定方法中的逻辑。

- Jim Panse

---

我个人会两者都做，因为接口是一个非常好的地方，可以有一个强大的代码文档（例如为什么需要抽象类），而不会搞乱Doctrine注释。如果你的AbstractVehicle实现了VehicleInterface，那么在期望一个车辆时，你可以对你的代码进行类型化（在我看来这是一个好习惯）。制作完接口之后，为什么要在每个类中复制/粘贴代码呢？总之，我会同时使用接口和抽象类。 - Zyigh

这个问题因为涉及个人观点而不适合在SO上讨论，但是在这里可能会更合适：https://softwareengineering.stackexchange.com - Script47

使用接口可以让您有机会使用多重继承。 - SynapseIndia

我在另一个社区发布了这个帖子 https://softwareengineering.stackexchange.com/questions/375461/should-i-use-an-abstract-class-or-an-interface-for-my-doctrine-model ... 谢谢。 - Jim Panse

创建一个MaterialInterface来标记你的代码对象有材质，然后创建一个MaterialTrait来实现你的getMaterial方法。这样可以避免需要抽象基类，同时减少重复的代码。 - Cerad

Answer 1

我的两分钱：

你可以编写一个抽象类，其中的方法返回null（或其他预定值），这将要求你在每个派生类中实现它们。

这种方法仍然需要你编写一些样板代码来检查每个类的条件。

我个人会选择在这里使用接口，因为你的类的性质似乎相当多样化，只能部分地归纳为单个抽象类。但是，我认为使用抽象类也没有任何问题。在这种情况下，魔鬼在于细节。

- Simas Joneliunas

---

你只需将这些函数声明为抽象函数，然后在每个子类中定义它们，而不是返回null或其他值。 - Nikita Leshchev