接口

如果从一个抽象类继承，并想创建该新类的对象，那么就必须为新类中的所有抽象方法提供方法定义，如果不这样做，那么导出类也是抽象类，且编译器会强制我们用abstract关键字来限定这个类；在抽象类中的抽象方法没有方法体

接口中的方法都是抽象的，没有方法体

接口被用来建立类与类之间的协议

interface不仅仅是一个极度抽象的类，因为它允许人们创建一个能够被向上转型为多种基类的类型，来实现某种类似多重继变种的特性

如果不添加public则只有包访问权限，接口也可以包含域，但是这些域都是隐式final和static的

创建一个能够根据所传参数对象的不同而具有不同行为的方法，被称为策略设计模式

使用接口的核心原因;为了能够向上转型为多个基类型，以及由此带来的灵活性；第二个原因与抽象类相同；

如果知道某事物应该作为一个基类，，那么第一选择应该是使他成为一个接口

可以通过继承扩展接口，而且可以通过extends继承多个接口，用逗号隔开

在组合接口时，可能引发名字冲突，所以在打算组合的不同接口中使用相同的方法名通常会造成代码可读性的混乱，请尽量避免这种情况。

static在类第一次加载时被初始化

接口可以嵌套其他类或者接口中

当需要实现某一个接口时，并不需要实现嵌套在其内部的接口。而且，private接口不能再定义它的类之外被实现

接口时实现多重继承的途径，而生成遵循某个接口的对象的典型方式就是工厂模式

 

总结

　　对于创建类，几乎任何时刻，都可以替代为创建一个接口和工厂
      许多人都掉进了这种诱惑的陷阱，只要有可能就去创建接口和工厂。这种逻辑看起来好像是因为需要使用不同的具体实现，因此总是应该添加这种抽象性。这实际上已经变成了一种草率的设计优化。

      任何抽象性都应该是应真正的需求而产生的。当必需时，你应该重构接口而不是到处添加额外级别的间接性，并由此带来的额外的复杂性。这种额外的复杂性非常显著，如果你让某人去处理这种复杂性，只是因为你意识到由于以防万一而添加了新接口，而没有其他更有说服力的原因，那么好吧，如果我碰上了这种事，那么就会质疑此人所作的所有设计了。

      恰当的原则应该是优先选择类而不是接口。从类开始，如果接口的必需性变得非常明确,那么就进行重构。接口是种重要的工具，但是它们容易被滥用。