网上理论型选手太多，收集了半天才有了一些自己的理解。

在我看来接口用处十分强大：

从设计理论及研发上看有两个用途1、面向接口开发，更容易实现系统解剖；2、抽象具象化程序类，减少开发时候的冗余代码，解耦。

实际应用上开，接口可以作为固化参数，选择实现类的作用。说的有点抽象，具体一点，举个可以反思的例子：

抽象一个接口执行数据入库操作

interface int_instert{
void insert(T);
}

然后实现两个接口实现的service

class A  implements int_instert{
@Override
void insert(T){
    //方法中向表A插入数据
}
}

 

class B  implements int_instert{
@Override
void insert(T){
    //方法中向表B插入数据
}
}

那么在我们开发的时候，经常碰到需要对应不同逻辑选择到底是用A或是B类（ps:如果这个时候你直接用DAO层进入逻辑，后期维护起来非常困难，耦合度太高），这时，我们就可以使用接口进行选择执行类了。方法如下：

先写一个事件：

class c{
private int_instert int;
public void register(int_instert int){
     this.int=int;//这里未来调用的时候就可以注入A或者B类了
}
public void dosomething(){
   this.int.insert()；//当注入了A或者B类后，这个方法就自动的指向了A或B类中的insert方法
}
}

再调用的时候，实际上只需要实现事件C类即可

C c = new c();

c.register(A/B);//选择你需要用的实现方法

c.inster();//这里就可以自动的使用选择好的类中方法。

 

很多人对接口不理解还是因为项目做的少，对后期修改等问题理解的不深入，后期面对大量耦合，阅读起来非常困难，然而使用接口可以解决阅读程序的问题，加快对程序的理解，并且也降低了耦合，例如需要调整AB中的方法，但调整量非常大至于会影响到现有业务的时候，这时，仅仅需要重新编写一份D类，注入的时候选择D类即可，其他的地方都不需要修改。这还是非常适合后期及多人团队的。

 

写到这里应该对接口算是有个大概理解了，到这里另外增加一个概念，就是监听的概念；

listener的整个思路还是没有跳脱事件传递，接口既然可以做到对象的注入，实际上就可以作为事件对象传递，这样一类也就解决了监听的问题。有点抽象？

具体：

前面的案例里是吧A或B类作为方法类注入，再监听里，我们新建一个事件E类实体：

class e{
@geter @seter
private C c;//这个时候我们把C作为事件源，就是说，一切操作C类的事件都作为触发器使用
construct（）....//省略了
}

再回到C类方法中：

class c{
private int_instert int;
public void register(int_instert int){
     this.int=int;//这里未来调用的时候就可以注入A或者B类了
}
public void dosomething(){
if(int !=null){//当产生事件时
E e=new e(this);//新事件纪录
this.int.insert()；//当注入了A或者B类后，这个方法就自动的指向了A或B类中的insert方法
}   
}
}

这样也就完成了监听器的建立，如果有需要，把e参数一起送给A或者B类，可以实现事件的关联，数据的统一传递。

接口是一个规范没错，但是再JAVA中综合使用上下文及反射的原理，可以实现非常出乎意料的功能。

都是手写，希望没有什么地方有错误。