每个基类设计的接口答案

【问题标题】：Interface per base class design每个基类设计的接口
【发布时间】：2018-09-23 12:31:26
【问题描述】：

考虑我有一个客户类，它有 CustomerTypeA、CustomerTypeB、CustomerTypeC 作为子类。

为 Customer 类实现 ICustomer 接口并创建子类型对象（CustomerTypeA、CustomerTypeB、CustomerTypeC）会是更好的设计吗

interface ICustomer {}

class Customer : ICustomer {}

class CustomerTypeA : ICustomer {}
class CustomerTypeB : ICustomer {}
class CustomerTypeC : ICustomer {}

ICustomer obj;
obj = new CustomerTypeB();

或

使用客户类对象声明创建子类的对象？

class Customer {}
class CustomerTypeA : Customer {}
class CustomerTypeB : Customer {}
class CustomerTypeC : Customer {}

Customer obj;
obj = new CustomerTypeB();

我应该如何选择要遵循的方法？

换句话说，每个父对象都从接口实现是不是更好的设计？它给我带来了什么好处？

谢谢

【问题讨论】：

你使用什么编程语言？
它的 C#。只是出于好奇，编程语言如何影响解决方案？
目前尚不清楚您正在考虑哪些替代方案。在一个版本中，您将有一个没有任何接口的基类和子类，而在另一个版本中，您将只有接口（每个“子类”一个）并且没有基类？可能只有一个基本接口？
C++、Perl、JavaScript、Common Lisp 没有接口。 Perl 具有您可以使用的角色，具体取决于。 Haskell 有类（在某种程度上），但没有子类型。
@user3738870 添加了示例示例 sn-p，可能有助于更好地理解问题

标签： c# oop interface methodology design-principles

【解决方案1】：

您可以使用其中任何一种，但人们越来越喜欢composition over inheritance。它在运行时提供了灵活性并增加了关注点的分离。

要确定最适合您的情况，您必须检查类型层次结构可能如何演变、您的实际需求是什么、您希望如何编写自动化测试等。

【讨论】：

与父类设计相比，基于接口的组合如何增加关注点分离？
@Ramu 这取决于你的情况。单继承不是问题。假设您有一个类是引擎，而您有另一个类 CarEngine。您可以拥有 carengine : eninge，但是当有 supercarengine : carengine 时，它会变得复杂。相反，您可以让 Supercarengine “拥有”汽车引擎功能，从而更容易设计。继承是一种关系，组合是一种关系
使用继承引入了行为的静态耦合（从子类到父类）。这意味着您从子类中获得的基本上总是基类行为加上一些修改（弱分离）。在许多情况下，这不是问题。但是您可能会遇到希望将子类的特定行为绑定到基类提供的 API 的其他实现的情况。使用组合，特定行为位于独立的类中，并通过基于接口的委托松散耦合。看看你的情况，然后决定你要做什么

【解决方案2】：

您通常可以同时使用两者。但是，如果在其他地方需要您的“客户”类，我要么选择第二个解决方案（简单继承），要么将第一个解决方案更改为此（假设您的 CustomerTypes 仍然与客户有共同点）：

interface ICustomer{}
class Customer:ICostumer{}
class CustomerTypeA:Customer{}
...

以及使用时：

ICustomer myCustomer=new CustomerTypeA();

【讨论】：

【解决方案3】：

我认为这只能通过对特定用例的更多了解来决定。你应该记住的是，在 C# 中你只能有一个基类。因此，只有在您不必从任何一个子类中的任何其他类继承时，您的第二种选择才能工作。

所以总的来说，我认为第一种方法更灵活，如果您想避免子类中的代码重复，您可能需要考虑在Customer类中实现共享逻辑，并尽可能从它继承.如果您的某个子类需要从不同的类继承，它当然仍然可以实现ICustomer。

另外，如果共享逻辑是一段较大的代码/功能并且您不能使用继承（因为存在另一个基类），您也可以考虑使用委托（组合而不是继承/策略模式）。

【讨论】：