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

现代风格是定义IPet和PetBase。

该接口的优点是其他代码可以使用它，而与其他可执行代码没有任何联系。完全“干净”。界面也可以混合。

但是基类对于简单的实现和通用实用程序很有用。因此，还提供一个抽象基类，以节省时间和代码。

通常，您应该喜欢接口而不是抽象类。使用抽象类的一个原因是，如果在具体类之间有共同的实现。当然，您仍然应该声明一个接口（IPet），并让一个抽象类（PetBase）实现该接口。使用小的、不同的接口，您可以使用多个来进一步提高灵活性。接口允许最大限度的灵活性和跨边界类型的可移植性。当跨越边界传递引用时，始终传递接口而不是具体类型。这允许接收端确定具体实施，并提供最大的灵活性。当以TDD/BDD方式编程时，这是绝对正确的。

“四人帮”在他们的书中说：“因为继承将子类暴露于其父类实现的细节，所以人们常说‘继承破坏了封装’。”。我相信这是真的。

下面是接口和基类的基本和简单定义：

基类=对象继承。接口=功能继承。

干杯

胡安，

我喜欢将接口视为一种描述类的方式。一个特定的犬类，比如约克郡梗，可能是母犬类的后代，但它也执行IFurry、IStubby和IYippieDog。所以类定义了类是什么，但接口告诉了我们关于它的事情。

这样做的好处是，例如，它允许我收集所有的IYippieDog，并将它们放入我的海洋收藏。因此，现在我可以跨越一组特定的对象，找到符合我所关注的标准的对象，而不必过于仔细地检查类。

我发现接口确实应该定义类的公共行为的子集。如果它为实现的所有类定义了所有公共行为，那么它通常不需要存在。他们没有告诉我任何有用的东西。

但这种想法与每个类都应该有一个接口的想法背道而驰，您应该编写接口代码。这很好，但最终会有很多一对一的类接口，这会让事情变得混乱。我知道这样做并不需要花费任何费用，现在你可以轻松地交换东西。然而，我发现我很少这样做。大多数时候，我只是在原地修改现有的类，如果该类的公共接口需要更改，我会遇到完全相同的问题，但我现在必须在两个地方更改它。

所以，如果你像我一样思考，你肯定会说《猫和狗》是IPettable的。这是一个符合两者的特征。

但另一个问题是，它们是否应该有相同的基类？问题是，它们是否需要被广泛地视为同一事物。当然，它们都是动物，但这是否符合我们将如何一起使用它们。

假设我想收集所有动物类并将它们放在我的方舟容器中。

或者它们需要是哺乳动物吗？也许我们需要某种跨动物挤奶工厂？

他们甚至需要联系在一起吗？仅仅知道它们都是IPettable就足够了吗？

当我真的只需要一个类时，我常常会感到想要派生出一个完整的类层次结构。我做这件事是为了期待有一天我可能会需要它，但通常我从来不会这样做。即使我做了，我通常也会发现我必须做很多事情来修复它。这是因为我创建的第一个类不是狗，我没有那么幸运，而是鸭嘴兽。现在，我的整个类层次结构都基于这个奇怪的案例，我有很多浪费的代码。

你可能还会发现，并不是所有的猫都是IPettable的（比如那个无毛的猫）。现在您可以将该接口移动到所有适合的派生类。你会发现，突然之间，猫不再是PettableBase的产物，这是一个小得多的变化。

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

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

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