设计模式之工厂模式

        我们如果要想去使用一个接口，那么一定要为接口定义他的子类，既然有了子类，那就可以按照子类对象的向上转型为接口对象进行实例化的处理操作，于是问题，也就从此出现了（我们开始讨论的不是行与不行，而是好与不好）。我们先来看一张图

interface IBook {
    public void read();
}

class ProgramBook implements IBook {

    @Override
    public void read() {
        System.out.println("【ProgramBook】认真学习编码，认真学习《Java基础》");
    }
}

public class Demo {
    public static void main(String[] args) {
        IBook book = new ProgramBook();
        book.read();
    }
}

        实际上这个程序所存在的最大的问题就在于主方法中的那个关键"new" （IBook book = new programBook();），因为这种代码一旦定义，就以为着主类和ProgramBook 这个子类捆绑在一起，那么这种操作就存在了很强的耦合性，所以在正常的项目过程之中一般常见的做法都是中间使用一个过渡层，例如：Java程序的可移植性原理 —— JVM。

        在以上例子中，按照同样的道理来讲，此时对于当前程序最大的问题就是客户端的程序类与接口的子类有了直接的耦合，而如果想要解决这个问题，最佳的做法就是引入一个中间的过渡类——工厂类。

interface IBook {
    public void read();
}

class ProgramBook implements IBook {

    @Override
    public void read() {
        System.out.println("【ProgramBook】认真学习编码，认真读《Java基础》");
    }
}

class MathBook implements IBook {

    @Override
    public void read() {
        System.out.println("【ProgramBook】认真学习数额学，认真读《数学》");
    }
}

class Factory{
    public static IBook getInstance(String className){
        if("program".equalsIgnoreCase(className)){
            return  new ProgramBook();
        }else if("math".equalsIgnoreCase(className)){
            return new MathBook();
        }

        return null;
    }
}

public class Demo {
    public static void main(String[] args) {
        IBook book = Factory.getInstance("program");
        book.read();
        book = Factory.getInstance("math");
        book.read();
    }
}

         统一以上代码分析之后可以发现，当前程序中的主类和接口的子类没有任何的直接联系，而所有的IBook接口对象全部是通过工厂类来获取的，这样就实现了解耦合的设计操作。