Java接口详解（二）

oldzhoua 2019-03-14

展开全文

上一篇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

以上程序非常简单，就是通过接口的子类为接口对象实例化，但这样操作会存在什么样的问题呢？在软件开发中，我们强调以下两点：
（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();    }}1
2
3
4
5
6
7
8
9
10

从上面我们发现，如果直接在客户端上产生一个实例化对象，那么我们每次要更换对象时，都需要修改客户端代码，这样的做法明显是不好的。而在整个代码中，我们最关心的是如何取得一个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();    }}1
2
3
4
5
6
7
8
9