从对象创建和引用小议解耦

核心提示： 在 清单 3 中，对工厂类 ExpressionEvaluatorFactory 做了修改，从对象创建和引用小议解耦(4)，在创建 ExpressionEvaluator 实例时，采取了常见的 Service Look-up 方式，其更关注的是如何使用 ExpressionEvaluator的功

在 清单 3 中，对工厂类 ExpressionEvaluatorFactory 做了修改，在创建 ExpressionEvaluator 实例时，采取了常见的 Service Look-up 方式。即依次通过如下方式搜索实现类：

读取系统属性，用户可以在应用启动时通过 -D 选项进行设置。

读取 JRE 目录中的某个属性文件，以获取实现类类名。

通过类载入器检索记录实现类类名的文件，常见的检索格式为 META=INF/services/ExpressionEvaluator.

如通过以上途经均未找到合适的实现类，则使用默认的实现类 ExpressionEvaluatorImpl。

事实上，在 Java EE 平台中，很多组件均使用此方式检索服务端接口的实现类，例如 javax.xml.bind.JAXBContext，javax.el.ExpressionFactory，javax.xml.soap.MessageFactory等。由此，不但避免了工厂类与实现类之间的紧耦合，而且提供多种策略在运行时获取实现类。可以预见，使用第三种方式实现的计算器应用，可以非常方便的更换 ExpressionEvaluator的实现类而无需修改和编译 ExpressionEvaluatorFactory的代码，例如在应用启动时设置对应系统属性值为实现类类名等。

继续观察包括 清单 3在内的以上实现方式，可以发现，无论是直接使用 new操作符创建，还是使用 ExpressionEvaluatorFactory工厂类创建，均是由 CalculatorUI负责 ExpressionEvaluator实现实例的创建。事实上，完全可以将相关逻辑从其中剥离出去，毕竟对于 CalculatorUI而言，它并不关心如何创建或者由谁去创建实例对象，其更关注的是如何使用 ExpressionEvaluator的功能。常见的解决方案之一是定义一个全局的注册表，服务的提供者和使用者分别在其中发布和获取相关服务。