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

接口有一个明显的优点，即对类来说有点“热交换”。将一个类从一个父类更改为另一个父级通常会导致大量工作，但通常可以删除和更改接口，而不会对实现类产生很大影响。这在您有几个“可能”希望类实现的窄行为集的情况下尤其有用。

这在我的领域尤其适用：游戏编程。基类可能会因继承对象“可能”需要的大量行为而变得臃肿。通过接口，可以轻松地向对象添加或删除不同的行为。例如，如果我为想要反映伤害的对象创建了“IDamageEffects”界面，那么我可以很容易地将其应用于各种游戏对象，并在以后很容易地改变主意。假设我设计了一个要用于“静态”装饰对象的初始类，我最初决定它们是不可破坏的。稍后，我可能会决定，如果它们可以爆炸，那会更有趣，所以我修改了类以实现“IDamageEffects”接口。这比切换基类或创建新的对象层次结构要容易得多。

我发现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)
}

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

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

还请记住，不要在OO中被卷走（请参见博客），并始终基于所需的行为来建模对象，如果您设计的应用程序中唯一需要的行为是动物的通用名称和物种，那么您只需要一个类animal，而不是世界上每种可能的动物都需要数百万个类。

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

一个重要的区别是，只能继承一个基类，但可以实现多个接口。因此，如果您绝对确定不需要同时继承不同的基类，那么只需要使用基类。此外，如果你发现你的接口越来越大，那么你应该开始把它分成几个逻辑块来定义独立的功能，因为没有规则规定你的类不能实现所有的功能（或者你可以定义一个不同的接口来继承所有的功能）。