我应该何时使用接口，何时使用基类？
如果我不想实际定义方法的基本实现，它应该始终是一个接口吗？
如果我有狗和猫的课。为什么我要实现IPet而不是PetBase？我可以理解为ISheds或IBarks（IMakesNoise？）提供接口，因为它们可以逐个宠物放置，但我不知道该为普通宠物使用哪个接口。
当前回答
除了那些提到IPet/PetBase实现的注释之外，在某些情况下，提供访问器帮助器类可能非常有价值。
IPet/PetBase风格假设您有多个实现，从而增加了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++），但能够实现多个接口，因此它允许您严格按照需要构造对象。
接口应较小。真的很小。如果你真的要分解你的对象，那么你的接口可能只包含一些非常具体的方法和财产。
抽象类是快捷方式。PetBase的所有衍生产品都有你可以编写一次代码并完成的东西吗？如果是的话，那么是抽象类的时候了。
抽象类也是有限的。虽然它们为您提供了生成子对象的绝佳捷径，但任何给定对象只能实现一个抽象类。很多时候，我发现这是抽象类的局限性，这也是我使用大量接口的原因。
抽象类可以包含多个接口。您的PetBase抽象类可以实现IPet（宠物有主人）和IDigestion（宠物吃，或者至少它们应该吃）。然而，PetBase可能不会实施IMammal，因为并非所有宠物都是哺乳动物，也并非所有哺乳动物都是宠物。您可以添加一个扩展PetBase的MammalPetBase并添加IMammal。FishBase可以有PetBase并添加IFish。IFish将使用ISwim和IUnderwaterBreaker作为接口。
是的，对于简单的示例来说，我的示例非常复杂，但这是接口和抽象类如何协同工作的一部分。
以前关于将抽象类用于公共实现的评论无疑是正确的。我还没有看到提到的一个好处是，使用接口可以更容易地实现用于单元测试的模拟对象。如Jason Cohen所描述的那样定义IPet和PetBase，使您能够轻松模拟不同的数据条件，而无需物理数据库的开销（直到您决定是时候测试真实数据为止）。
不要使用基类，除非您知道它的含义，并且它适用于这种情况。如果适用，使用它，否则使用接口。但请注意关于小接口的答案。
公共继承在OOD中被过度使用，表达的内容比大多数开发人员意识到或愿意实现的要多得多
简而言之，如果A“是一个”B，那么对于它公开的每个方法，A需要的不超过B，交付的不少于B。
这是非常特定于.NET的，但《框架设计指南》一书认为，一般来说，类在不断发展的框架中提供了更多的灵活性。一旦一个接口交付，您就没有机会在不破坏使用该接口的代码的情况下更改它。然而，对于类，你可以修改它，而不是破坏链接到它的代码。只要你做了正确的修改，包括添加新的功能，你就可以扩展和发展你的代码。
Krzysztof Cwalina在第81页上说：
在.NETFramework的三个版本中，我已经与我们团队中的许多开发人员讨论了这一指南。他们中的许多人，包括那些最初不同意该指南的人，都表示他们后悔将一些API作为接口提供。我甚至没有听说过一个案例，其中有人后悔他们运送了一节课。
也就是说，当然有接口的地方。作为一般准则，始终提供接口的抽象基类实现，作为实现接口的方法的示例。在最佳情况下，基类将节省大量工作。
