C# 这段代码应该是基类而不是接口吗？

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

InsertDate
InsertENTUserAccountId
UpdateDate
UpdateENTUserAccountId
Version

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

更新

---

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

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

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

好吧，接口通常是首选的，因为它允许更大的灵活性和抽象性，但是您可以通过让

抽象
基类实现接口来实现这两个功能。然后95%的时间使用基类，当需要不同的东西时，只需使用接口

只是不要从您的业务代码中接触基类。。。只有界面。基类只是一个实现细节。
好吧，接口通常是首选的，因为它允许更大的灵活性和抽象性-但您可以通过让您的
抽象
基类实现接口来实现这两个功能。然后95%的时间使用基类，当需要不同的东西时，只需使用接口

只是不要从您的业务代码中接触基类。。。只有界面。基类只是一个实现细节。
通过使用接口，您需要在实现接口的所有类中实现所有这些属性。如果所有的实现都是相同的，那么这是大量重复的代码。这可以通过让基类实现接口来缓解

通过使用基类，您可以在所有子类之间共享相同的实现。如果需要对其他内容进行子类化，就会出现问题，因为.NET不允许多重继承。通过这种方式，您必须直接实现接口（可能使用组合）。
通过使用接口，您需要在实现接口的所有类中实现所有这些属性。如果所有的实现都是相同的，那么这是大量重复的代码。这可以通过让基类实现接口来缓解

通过使用基类，您可以在所有子类之间共享相同的实现。如果需要对其他内容进行子类化，就会出现问题，因为.NET不允许多重继承。这样，您就必须直接实现接口（可能使用组合）。
他保证它们在那里，而无需提前定义它们必须是什么。与直接继承相比，这些可能与行为更相关。如果它们是行为关系，而不是直接为is-a关系继承，那么接口是最好的，可能是唯一的方法

编辑：如果你想一想，不是所有的表都有相同的数据，但是它们都与帐户有关。这是行为关系，而不是is-a关系，因此是接口。
他保证他们在那里，而不定义他们必须提前做什么。与直接继承相比，这些可能与行为更相关。如果它们是行为关系，而不是直接为is-a关系继承，那么接口是最好的，可能是唯一的方法

编辑：如果你想一想，不是所有的表都有相同的数据，但是它们都与帐户有关。这是行为关系，而不是is-a关系，因此是接口。
要定义类的公共“契约”，我通常会使用接口。然后，我可能会定义一个抽象基类，它提供一些默认实现，并实现接口定义的全部或部分“契约”。在每个类的实现不同的情况下，我可能会忽略抽象基类。不过，我通常不会定义没有接口的抽象基类。我的实体也可能实现多个接口。
要定义类的公共“契约”，我通常会使用接口。然后，我可能会定义一个抽象基类，它提供一些默认实现，并实现接口定义的全部或部分“契约”。在每个类的实现不同的情况下，我可能会忽略抽象基类。不过，我通常不会定义没有接口的抽象基类。我的实体也可能实现几个接口。
有点像其他人所说的，但我的简单想法是：


如果您希望它从外观上看起来相同，请将其作为一个接口
如果您希望它在内部是相同的，请将其作为基类
你可能想两者兼而有之
有点像其他人说的，但我的想法很简单：


如果您希望它从外观上看起来相同，请将其作为一个接口
如果您希望它在内部是相同的，请将其作为基类
你可能想两者兼而有之
我认为查看界面的最佳方式是：
“将由实现该接口的类提供的列表服务”。
例如ISwitchable，实现该接口的所有类都提供了一种切换方式（在接口中定义）。ISwitchable的实现可以是一个按钮

另一方面，基本/子类关系可以描述为：
子类是基类的特化。
所以如果你有一个宠物作为b
IBaseInterface {
 //basic fields
}

ITable1Interface : IBaseInterface

BaseClass : IBaseInterface {
  //basic fields implementation
}

Table1Class : BaseClass...