1、接口编程的好处
我们知道，在实际的项目开发中，客户的需求是经常发生变化的。那如果说，我们不采用接口编程，那我们就必须修改我们业务层的代码。长此以往，这样做的后果是什么呢？答：bug多，不易维护，接手困难
如果我们采用接口编程的话：我们只需要在接口中把客户的需求提取出来， 写在接口中。这样，客户的需求变化时，我们可以实现响应接口的新的实现类，这样就不需要更改原来的代码，这样就避免了诸多问题。
另外，在设计模式的原则里的开闭原则，就是要使用接口来实现对扩展开放，对修改关闭。这样也是为了减少各个类之间的依赖。
还有就是，接口开发，小组成员分工合作，互不干扰。适于团队的协作开发。
2、接口编程的缺点
接口编程也不尽然都是好处。缺点就是接口设计困难，因为，还没实现，就得把所有的东西想好。
3、实现方式的选择。
先来看个例子：
interface A { //接口A
public void eat();
}
public class B implements A {
@Override
public void eat() {
System.out.println("吃");
}
public void drink(){
System.out.println("喝");
}
}两种方式
A a = new B();//向上转型，即类B的对象的引用赋值给接口
B b = new B();//正常的实例化。我们先来看第一种：
这种方式，在上面的例子中，只能这样写： a.eat()
而当你这样写时： a.drink()这种方式是会报错的。错误内容为： The method drink() is undefined for the type A
这是因为，在本例中，B在向上转型为A的时候，是“失去”，而非“得到”。也就是说，“a”的功能窄化！
如果这样写： ((B)a).drink()//向下转型是可以调用的。
我们在来看第二种：
第二种理所当然了，连个方法都可以调用。无需多言。
那我们的结论是什么？
应该优先使用第一种，前提时，存在“合理”的接口时
应
该
优
先
使
用
第
一
种
，
前
提
时
，
存
在
“
合
理
”
的
接
口
时
