依赖注入及AOP简述（二）——工厂和ServiceLocator .

2.2.    工厂模式

基于手工构建组件的诸多弱点，1995年“大师4人组”（GoF）在其经典著作《DesignPatterns》一书中提出了“工厂模式”，这种模式在一定程度上有效的解决了之前所遇到的问题，时至今日仍然被大量应用于软件工程的设计当中。

我们先来看之前的例子，首先来创建一个银行工厂和一个存折工厂，用于创建这两个依赖对象。

public class BankFactory {

    public Bank createBankICBC() {

        return new BankICBC("Tianjin", 100);

    }

}

 

public class DepositBookFactory {

    public DepositBook createDepositICBC() {

        return new DepositBookICBC("62202", "current", "CNY");

    }

}

 

 

有了这两个能够创建依赖对象的工厂，我们就可以在储户类Depositor中利用它们方便的构建出银行和存折这两个依赖。

public class Depositor {

    private Bank bank;

    private DepositBook depositBook;

   

    public Cash withDraw(BigDecimal amount) {

        bank = new BankFactory().createBankICBC(); // 工厂创建依赖

        depositBook = new DepositBookFactory().createDepositICBC();// 工厂创建依赖

        return bank.withDraw(depositBook, amount);

    }

}

 

 

我们可以看到，用工厂创建依赖对象，可以将创建对象的过程隐蔽，Depositor类的开发者利用这种透明创建对象的方式则可避免手工构建复杂依赖关系图所带来的诸多不便。并且，当依赖的构造方法接口发生变更时，影响到的也只是工厂类，而不会影响到调用工厂类的依赖者类本身，从而降低了系统的维护成本。

在实际的开发中，工厂往往是被定义为静态的单例模式的，即在一个JVM中有且仅有一个工厂的实例。但由于静态单例模式有很多的缺陷，因此在依赖注入框架流行之后这种模式已经渐渐的被抑制使用了。

但是随着软件工程的不断复杂化和规模化，工厂模式同样的遇到了很多问题而被开发人员诟病。围绕着这个话题的讨论有很多，我们不再一一列举，只举一个比较常见的问题来说明一下。

假设我们的银行不只有工商银行，还有招商银行、中国银行等等，这样就需要我们维护一个越来越庞大的工厂类。之前的Bank工厂就要逐渐这样增加create方法：

public class BankFactory {

    public Bank createBankICBC() {

        return new BankICBC("Tianjin", 100);

    }

    public Bank createBankCMB() { // …… };

    public Bank createBankBOC() { // …… };

    // ……

}

 

 

这样工厂类自身的维护成本逐渐增大，就成为了工厂模式的一个很大的障碍。因此很多开发者想办法用参数化的形式，来减少工厂类的维护量。

public class BankFactory {

    public Bank createBank(BankVender bankVendor) { // 参数化的工厂方法

        switch (bankVendor) {

        case ICBC:

            return createBankICBC();

        case CMB:

            return createBankCMB();

        default:

            return createBankICBC();

        }

    }

    // ……

}

 

 

但是这样一来又会回到手工new对象的一个问题，即如果工厂方法的参数发生了变化，可能会引起全部调用到该工厂方法的代码都需要修改及做相应的回归测试。

2.3.    ServiceLocator模式

基于上面工厂模式的诸多问题，一些聪明的开发者提出了改进版的工厂模式：ServiceLocator，即服务定位器。这种模式的核心思想是，将构建依赖的接口彻底与依赖者分离，并将此依赖作为“服务”绑定到一个标识符（通常是一个字符串），而后依赖者则可通过这个标识符获取被绑定的依赖。例如我们的例子中，可以这样获得Bank和DepositBook的依赖：

public class Depositor {

    private Bank bank;

    private DepositBook depositBook;

   

    public Cash withDraw(BigDecimal amount) {

        bank = (Bank) new ServiceLocator().get("BankICBC");

        depositBook = (DepositBook) new ServiceLocator().get("DepositBookICBC");

           // 从ServiceLocator容器中获取依赖对象

 

        return bank.withDraw(depositBook, amount);

    }

}

 

 

此处ServiceLocator#get(String)这个API的String型参数即为“服务”的标识符。那么这个标识符是如何被绑定到依赖的对象上的呢？答案是开发者需要实现一个能够管理这些依赖（即“服务”）的、类似于工厂类的一个单独的类，这也常常被称作“ServiceLocator容器”，这个容器负责各种依赖的注册、标识符绑定、提供依赖对象等工作。

说到此处大家一定会觉得开发这样一个ServiceLocator容器花的代价一定不小。不错，正因为如此，JCP组织联合各IT供应商制订了统一的ServiceLocator容器标准，开发者可以只管开发自己的依赖类，然后IT供应商提供的ServiceLocator容器实现（即各种应用服务器级中间件）通过统一的命名规则将某个标识符绑定到这些依赖类并注册到容器中，等待开发者的请求命令。

而ServiceLocator模式作为业界标准统一化后，一个最典型的应用便诞生了：JNDI。直到今天JNDI都是组件、包括分布式组件开发中不可或缺的耦合方式。例如DataSource资源的获取、RemoteEJB对象的获取等等，都是通过JNDI查找的方式进行的。例如获取RemoteEJB的时候，我们可以执行这样的JNDI查找：

RemoteBean rb = (RemoteBean) initialContext.lookup("java:comp/env/TEST/RemoteBeanImpl");

 

 

但是ServiceLocator模式最大的弱点就是，依赖对象的获取强依赖于ServiceLocator容器，除非开发者愿意花费大量成本自己实现ServiceLocator容器，否则就必须要中间件提供商的支持，这就给我们的开发和测试带来了很大困扰。拿JNDI容器的实现来说，各提供商，比如Tomcat、JBoss、WebLogic、WebSphere等，对于JNDI的统一命名标识符的规则就不尽相同，使得开发者往往必须通过各自应用服务器的控制台才能准确找到需要的JNDI名，并且在单元测试时如果没有应用服务器启动下的环境，单元测试是难以顺利进行的，给维护带来了不小的困扰。