我应该何时使用接口，何时使用基类？
如果我不想实际定义方法的基本实现，它应该始终是一个接口吗？
如果我有狗和猫的课。为什么我要实现IPet而不是PetBase？我可以理解为ISheds或IBarks（IMakesNoise？）提供接口，因为它们可以逐个宠物放置，但我不知道该为普通宠物使用哪个接口。
当前回答
现代风格是定义IPet和PetBase。
该接口的优点是其他代码可以使用它，而与其他可执行代码没有任何联系。完全“干净”。界面也可以混合。
但是基类对于简单的实现和通用实用程序很有用。因此，还提供一个抽象基类，以节省时间和代码。
其他回答
让我们以Dog和Cat类为例，使用C#进行演示：
狗和猫都是动物，特别是四足哺乳动物（动物太普通了）。让我们假设您有一个抽象类Mammal，用于这两个类：
public abstract class Mammal
此基类可能具有默认方法，例如：
喂养朋友
所有这些都是在两个物种之间或多或少具有相同实现的行为。要定义此项，您需要：
public class Dog : Mammal
public class Cat : Mammal
现在让我们假设还有其他哺乳动物，我们通常会在动物园里看到：
public class Giraffe : Mammal
public class Rhinoceros : Mammal
public class Hippopotamus : Mammal
这仍然有效，因为Feed（）和Mate（）功能的核心仍然相同。
然而，长颈鹿、犀牛和河马并不是你可以用来做宠物的动物。这就是界面将有用的地方：
public interface IPettable
{
IList<Trick> Tricks{get; set;}
void Bathe();
void Train(Trick t);
}
上述合同的执行在猫和狗之间是不同的；将它们的实现放在抽象类中继承将是一个坏主意。
狗和猫的定义现在应该如下：
public class Dog : Mammal, IPettable
public class Cat : Mammal, IPettable
理论上，您可以从更高的基类重写它们，但本质上，接口允许您只将所需的内容添加到类中，而不需要继承。
因此，由于您通常只能从一个抽象类继承（在大多数静态类型的OO语言中，即……例外包括C++），但能够实现多个接口，因此它允许您严格按照需要构造对象。
用你自己的判断，要聪明。不要总是照别人（像我）说的做。你会听到“更喜欢接口而不是抽象类”，但这取决于实际情况。这取决于班级。
在上面提到的情况下，我们有一个对象层次结构，接口是一个好主意。接口有助于处理这些对象的集合，在实现服务时也有助于使用层次结构中的任何对象。您只需定义一个用于处理层次结构中的对象的契约。
另一方面，当您实现一组共享公共功能的服务时，您可以将公共功能分离为一个完整的单独类，也可以将其移动到一个公共基类中，并使其抽象化，以便没有人可以实例化基类。
还要考虑如何随时间推移支持抽象。接口是固定的：您将一个接口作为任何类型都可以实现的一组功能的契约发布。基类可以随着时间的推移而扩展。这些扩展成为每个派生类的一部分。
这取决于您的要求。如果IPet足够简单，我更愿意实现它。否则，如果PetBase实现了大量您不想复制的功能，那么就试试看。
实现基类的缺点是需要重写（或新的）现有方法。这使它们成为虚拟方法，这意味着您必须小心如何使用对象实例。
最后，.NET的单一继承让我很头疼。一个天真的例子：假设你正在创建一个用户控件，那么你就继承了UserControl。但是，现在你被禁止继承PetBase。这迫使您重新组织，例如创建PetBase类成员。
不要使用基类，除非您知道它的含义，并且它适用于这种情况。如果适用，使用它，否则使用接口。但请注意关于小接口的答案。
公共继承在OOD中被过度使用，表达的内容比大多数开发人员意识到或愿意实现的要多得多
简而言之，如果A“是一个”B，那么对于它公开的每个方法，A需要的不超过B，交付的不少于B。
我有一个粗略的经验法则
功能：可能在所有部分都不同：界面。
数据和功能，部分基本相同，部分不同：抽象类。
数据和功能，实际工作，如果只进行了轻微的修改：普通（具体）类
数据和功能，没有计划的更改：带有最终修饰符的普通（具体）类。
数据，可能还有功能：只读：枚举成员。
这是非常粗略和准备好的，并且根本没有严格定义，但是有一个范围是从所有内容都要更改的接口到所有内容都像只读文件一样固定的enums。
