这段代码应该是Base类而不是Interface吗？

Question

接口与基类对我来说仍然是一个相当灰色的区域。我正在读一本关于ASP.NET 3.5企业开发的书，作者声明所有表都有以下字段：

InsertDate
InsertENTUserAccountId
UpdateDate
UpdateENTUserAccountId
Version

如果这是我编写上述要求的代码，我将创建一个包含这些字段的基本业务对象类，并且所有业务对象都将从中继承。但是，作者将这些创建为接口。馊主意？好主意？没关系？

更新

有一个实现此接口的基类。看来所有业务对象都将从基础继承。但即使如此，我还是将这个接口放在基类中......？

Answer 1

嗯，通常首选接口，因为它允许更大的灵活性和抽象 - 但是你可以通过让abstract基类实现接口来做到这两点。然后95％的时间使用基类，当你需要不同的东西时，你只需使用界面。

只是不要触摸业务代码中的基类...只接触界面。基类只是一个实现细节。

Answer 2

通过使用接口，您需要在实现该接口的所有类中实现所有这些属性。如果所有人的实现都相同，那么这就是很多重复的代码。这可以通过让基类实现接口来缓解。

通过使用基类，您可以在所有子类之间共享相同的实现。如果您需要继承其他内容，则会出现问题，因为.NET不允许多重继承。这样你就必须直接实现接口（可能使用合成）。

Answer 3

他保证他们在那里，而没有提前确定他们必须做什么。与直接继承相反，这些也可能与行为更相关。如果它们是行为关系而不是直接继承is-a关系，那么界面是最好的，也许只是这样做。

编辑：如果您考虑一下，并非所有表都有相同的数据，但他们都必须对该帐户执行某些操作。这是行为关系，而不是is-a关系，因此是接口。

Answer 4

要定义类的通用“契约”，我通常会使用一个接口。然后我可以定义一个抽象基类，它提供一些默认实现，并完成接口定义的全部或部分“契约”。如果每个类的实现都不同，我可能会省略抽象基类。但是，我通常不会定义没有接口的抽象基类。我的实体也可能实现多个接口。

Answer 5

其他人说的那种，但我简单的思考方式：

• 如果您希望它从外部看起来相同，请将其设为界面。
• 如果你想让它在内部相同，那就把它作为基类。
• 你可能想要两者兼顾。

Answer 6

我认为查看界面的最佳方式是： “将由实现该接口的类提供的列表服务”。 一个例子是ISwitchable，所有实现此接口的类都提供了一种切换方式（在接口中定义）。 ISwitchable的实现可以是一个按钮。

另一方面，基础/子类关系可以描述为： 子类是基类的特化。 因此，如果您有一只宠物作为基类，您可以让狗从基地派生，因为它是宠物的专业化。你不能说狗提供宠物服务。在这个例子中，dog类可以实现IBrag接口。

我不同意这里的一些答案，说“什么时候”应该是一个接口或基类。它是建模过程的一部分，因此它依赖于业务对象和上下文，而某些东西应该是接口或基类。

Answer 7

如果你永远不需要实例化它，那么它就是一个接口，否则它就是一个基类。

Answer 8

将其创建为仅的接口，因为所有的代码重复都是一个坏主意，在这种情况下最合适的是两者兼而有之，你可以拥有一个基类和一个基础所有其他表接口都从

继承的接口

IBaseInterface {
 //basic fields
}

ITable1Interface : IBaseInterface

BaseClass : IBaseInterface {
  //basic fields implementation
}

Table1Class : BaseClass...

Answer 9

我认为你应该在接口中考虑类型应该实现的行为，而不必考虑这种类型是什么。它们应该是轻量级的，并允许扩展您的对象和第三方对象。基类有更多关于将继承它的类族，因此应该有一些语义关系。当然，你可以同时使用两者，这是一种可能性。您应该有一个ILoggable接口（我猜您正在使用该信息进行日志记录）或其他任何东西，并且基于您的系统体系结构，您可以拥有一个或多个实现此接口的基类，以避免编码重复代码，例如，一个将实现ILoggable并且Person对象继承它的AbstractPerson，这种方法在将来是可扩展的，很容易在别人的代码中实现，并且给你一个灵活性。