通过def，接口提供了一个与其他代码通信的层。默认情况下，类的所有公共财产和方法都实现隐式接口。我们也可以将接口定义为一个角色，当任何类都需要扮演这个角色时，它必须实现它，根据实现它的类，给它不同的实现形式。oops的两个概念！！！

我发现Interface>Abstract>Concrete的模式适用于以下用例：

1.  You have a general interface (eg IPet)
2.  You have a implementation that is less general (eg Mammal)
3.  You have many concrete members (eg Cat, Dog, Ape)

抽象类定义了具体类的默认共享属性，但实施了接口。例如：

public interface IPet{

    public boolean hasHair();

    public boolean walksUprights();

    public boolean hasNipples();
}

现在，由于所有的哺乳动物都有毛发和乳头（AFAIK，我不是动物学家），我们可以将其纳入抽象基类

public abstract class Mammal() implements IPet{

     @override
     public walksUpright(){
         throw new NotSupportedException("Walks Upright not implemented");
     }

     @override
     public hasNipples(){return true}

     @override
     public hasHair(){return true}

然后具体的类仅仅定义了他们直立行走。

public class Ape extends Mammal(){

    @override
    public walksUpright(return true)
}

public class Catextends Mammal(){

    @override
    public walksUpright(return false)
}

当有很多具体的类时，这种设计是很好的，并且您不希望维护样板只是为了编程到接口。如果向接口中添加了新方法，则会破坏所有生成的类，因此您仍然可以获得接口方法的优势。

在这种情况下，抽象也可以是具体的；然而，抽象的名称有助于强调这种模式正在被使用。

通过def，接口提供了一个与其他代码通信的层。默认情况下，类的所有公共财产和方法都实现隐式接口。我们也可以将接口定义为一个角色，当任何类都需要扮演这个角色时，它必须实现它，根据实现它的类，给它不同的实现形式。oops的两个概念！！！

当我第一次开始学习面向对象编程时，我犯了一个简单的、可能也是常见的错误，即使用继承来共享公共行为——即使这种行为对对象的本质来说并不重要。

为了进一步建立这个问题中经常使用的例子，有很多东西都是可拍的——女朋友、汽车、毛毯所以我可能有一个Petable类提供了这种常见的行为，以及从中继承的各种类。

然而，可拍不是这些物体的本质的一部分。还有很多更重要的概念对他们的天性至关重要——女朋友是人，汽车是陆地车辆，猫是哺乳动物。。。

行为应该首先被分配给接口（包括类的默认接口），并且只有当它们（a）对于作为更大类的子集的一大群类来说是公共的时，才应该被提升为基类——在相同的意义上，“猫”和“人”是“哺乳动物”的子集。

问题是，当你比我一开始更了解面向对象设计之后，你通常会自动完成这项工作，甚至不用考虑它。因此，“代码到接口，而不是抽象类”这句话的真实性变得如此明显，你很难相信任何人都会不厌其烦地说出它，并开始尝试将其他含义解读到其中。

我想补充的另一点是，如果一个类是纯抽象的-没有非抽象的、非继承的成员或方法暴露给子级、父级或客户端-那么为什么它是一个类？它可以被替换，在某些情况下被接口替换，在其他情况下被Null替换。

另一个要记住的选项是使用“has-a”关系，也就是“以”或“组合的方式实现”。有时这是一种比使用“is-a”继承更干净、更灵活的结构方式。

从逻辑上说，狗和猫都“拥有”一只宠物可能不太合理，但它避免了常见的多重继承陷阱：

public class Pet
{
    void Bathe();
    void Train(Trick t);
}

public class Dog
{
    private Pet pet;

    public void Bathe() { pet.Bathe(); }
    public void Train(Trick t) { pet.Train(t); }
}

public class Cat
{
    private Pet pet;

    public void Bathe() { pet.Bathe(); }
    public void Train(Trick t) { pet.Train(t); }
}

是的，这个例子表明，在以这种方式做事时存在大量的代码重复和缺乏优雅。但我们也应该意识到，这有助于保持狗和猫与宠物类的分离（因为狗和猫不能访问宠物的私人成员），并为狗和猫从其他东西（可能是哺乳动物类）继承留下了空间。

当不需要私人访问并且您不需要使用通用的宠物参考/指针来参考狗和猫时，合成是最好的。接口为您提供了通用的引用功能，可以帮助减少代码的冗长，但当组织不好时，它们也会使事情变得模糊。当您需要私人成员访问时，继承是有用的，在使用它时，您将致力于将您的狗和猫类与您的宠物类高度耦合，这是一个巨大的成本。

在继承、组合和接口之间，没有一种方法总是正确的，考虑如何协调地使用这三种选项是有帮助的。在这三个选项中，继承通常是最不常用的选项。

从概念上讲，接口用于正式和半正式地定义对象将提供的一组方法。形式上表示一组方法名称和签名，半形式上表示与这些方法相关的人类可读文档。

接口只是API的描述（毕竟，API代表应用程序编程接口），它们不能包含任何实现，也不可能使用或运行接口。它们只明确约定你应该如何与对象交互。

类提供了一个实现，它们可以声明它们实现了零个、一个或多个接口。如果要继承类，则惯例是在类名前面加上“Base”。

基类和抽象基类（ABC）之间有区别。ABC将接口和实现混合在一起。计算机编程之外的抽象意味着“摘要”，即“抽象==接口”。然后抽象基类可以描述接口，也可以描述要继承的空的、部分的或完整的实现。

关于何时使用接口、抽象基类还是仅使用类的意见将根据您正在开发的内容以及您正在使用的语言而大不相同。接口通常仅与静态类型语言（如Java或C#）相关，但动态类型语言也可以有接口和抽象基类。例如，在Python中，Class和对象之间的区别很明显，前者声明它实现了一个接口，后者是一个类的实例，据说提供了该接口。在动态语言中，两个都是同一类实例的对象可以声明它们提供完全不同的接口。在Python中，这仅适用于对象属性，而方法在类的所有对象之间共享状态。然而，在Ruby中，对象可以具有每实例方法，因此同一类的两个对象之间的接口可能会根据程序员的需要而变化（然而，Ruby没有任何明确的接口声明方式）。

在动态语言中，对象的接口通常是隐式假设的，可以通过内省对象并询问它提供了什么方法（在跳转之前查看），也可以通过简单地尝试在对象上使用所需的接口并在对象不提供该接口时捕捉异常（请求原谅比请求许可更容易）。这可能导致“误报”，即两个接口具有相同的方法名称，但语义不同。然而，权衡是代码更加灵活，因为您不需要预先过度指定以预测代码的所有可能用途。