上一篇Java接口 详解（一）讲到了接口的基本概念、接口的使用和接口的实际应用（标准定义）。我们接着来讲。
一、接口的应用—工厂设计模式（Factory）
我们先看一个范例：
package com.wz.factoryDemo;
interface Fruit{
public void eat();
}
class Apple implements Fruit{
@Override
public void eat() {
System.out.println("吃苹果。。。");
}
}
public class Client {
public static void main(String[] args) {
Fruit f = new Apple();
f.eat();
}
}
运行结果：
吃苹果。。。
以上程序非常简单，就是通过接口的子类为接口对象实例化，但这样操作会存在什么样的问题呢？在软件开发中，我们强调以下两点：
（1）主方法或主类是一个客户端，客户端的操作应该越简单越好；
（2）客户端之外的代码修改，不影响用户的使用。也就是说，用户可以不用去关心代码是否由变更。
确实，以上范例没有任何语法错误，但关键的问题是客户端中出现的new关键字上。因为，一个接口会有多个子类，对于上面的Furit接口，也可能出现多个子类对象。
来看范例，我们多加上一个接口子类：
class Orange implements Fruit{
@Override
public void eat() {
System.out.println("吃橘子。。。");
}
}客户端是若要得到这个新的子类对象，需要修改代码为：
public class Client {
public static void main(String[] args) {
//Fruit f = new Apple();
Fruit f = new Orange();
f.eat();
}
}从上面我们发现，如果直接在客户端上产生一个实例化对象，那么我们每次要更换对象时，都需要修改客户端代码，这样的做法明显是不好的。而在整个代码中，我们最关心的是如何取得一个Fruit接口对象，然后进行方法的调用，至于这个接口对象时被谁实例化的，不是客户端关心的。这个问题就是代码耦合度太高！耦合度太高的产生的直接问题是代码不方便维护。
在本程序之中，最大的问题在于耦合上，发现在主方法中，一个接口和一个子类紧密耦合在一起，这种方式比较直接，可以简单的理解为由A —>B，但是这种紧密的方式不方便于维护，所以我们可以这样改：A—> C—>B，中间经历了一个过渡，这样一来，B改变，然后C去改变，但是A不需要改变。这可以参考Java中JVM的设计思想：程序—> JVM—>适应不同的操作系统。
于是，本程序我们这么修改，加上一个工厂类：
class Factory{
public static Fruit getInstance(String className){
if("apple".equals(className)){
return new Apple();
}else if("orange".equals(className)){
return new Orange();
}else{
return null;
}
}
}然后修改客户端：
public class Client {
public static void main(String[] args) {
Fruit f = Factory.getInstance("apple");
f.eat();
}
}运行结果：
吃苹果。。。这样的话，客户端不会看见具体的子类，客户端不再和一个具体的子类耦合在一起了，就算以后增加了新的子类，那么只需要修改Factory类即可实现，客户端的调用不会改变。
工厂模式的关系图如下：
从工厂模式关系图看出，客户端不和具体的子类耦合在一起，若要增加新的子类，只需要修改Factory类即可实现。
二、接口的应用—代理设计模式（Proxy）
Java代理设计模式单独讲解，请移步到Java设计模式之代理模式
所谓代理，就是一个人或者机构代表另一个人或者机构采取行动。在一些情况下，一个客户不想或者不能够直接引用一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。
关系图如下：
代理设计模式的核心精髓就在于：有一个主题操作接口（接口中可能有多个方法），而核心业务主题只完成核心功能，而代理主题负责完成所有与核心主题有关的辅助性操作。
三、Java抽象类和接口的区别
通过上面的分析可以得出结论：在开发之中，抽象类和接口实际上都是可以使用的，并且使用那一个都没有明确的限制，可是抽象类有一个最大的缺点 ： 一个子类只能够继承一个抽象类，存在单继承的局限。所以当遇到抽象类和接口都可以使用的情况下，优先考虑接口，避免单继承局限。
一些参考原则（根据自身情况参考）：
（1）在进行某些公共操作的时候一定要定义出接口；
（2）有了接口就需要利用子类完善方法；
（3）如果是我们自己写的接口，尽量不要使用关键字new去直接实例化接口子类，要使用工厂类完成。