为了软件系统在系统层级上保持整洁,需要为系统演化出恰当的抽象等级和模块。其中一个有效的方法就是将系统的构造和使用分开,因为构造和使用是非常不一样的过程。
软件系统应将启始过程和启始过程之后的运行时逻辑分离开,如果在启始过程中构建应用对象,将会存在相互缠结的依赖关系。将关注的方面分离开,是软件技艺中最古老也是最重要的设计技巧。不幸的是,多数应用程序没能做到分离处理,启始过程代码很特殊,被混杂到运行时逻辑中,下面的代码片段是著名的延迟初始化/赋值,这种处理的好处是在真正用到对象之前,无需操心这种架空构造,启始时间也会缩短,而且能够保证永远不会返回null值。
public Service getService() {
if (null == service) {
service = new MyServiceImpl(...);
}
return service;
}
但是存在一个问题,我们在得到service的同时,必须硬编码依赖于MyServiceImpl及其构造器所需一切。不分解这些依赖关系就无法编译,即使在运行时永不使用这种类型的对象。
如果MyServiceImpl是个重型对象,那么进行单元测试前,需要给service指派恰当的测试替身(Test Double)或者仿制对象(Mock Object)。
为了解决上面的依赖问题,我们有三种方法:
1)分解Main
将构造和使用分开的方法之一是将全部构造过程移到main或被称为main的模块中,设计系统的其余部分时,假设所有对象都已正确构造和设置。如图,main函数负责调用Builder创建系统所需的对象,再传递给应用程序application,应用程序只负责使用。从箭头的方向可知,应用程序对main或者构造过程一无所知,它只是简单地指望一切已就绪。
简单实现的代码如下:
/**
* 某配置对象,供Applicaton使用,由Builder创建
* @author ASCE1885
*
*/
public class ConfiguredObject {
private String majorVersion;
private String minorVersion;
public String getMajorVersion() {
return majorVersion;
}
public void setMajorVersion(String majorVersion) {
this.majorVersion = majorVersion;
}
public String getMinorVersion() {
return minorVersion;
}
public void setMinorVersion(String minorVersion) {
this.minorVersion = minorVersion;
}
public ConfiguredObject(String majorVersion, String minorVersion) {
this.majorVersion = majorVersion;
this.minorVersion = minorVersion;
}
public ConfiguredObject() {
}
}
/**
* 负责创建ConfiguredObject
* @author ASCE1885
*
*/
public class Builder {
private ConfiguredObject configuredObject = null;
//延迟初始化
public ConfiguredObject createConfiguredObject(String majorVersion, String minorVersion) {
if (null == configuredObject) {
configuredObject = new ConfiguredObject(majorVersion, minorVersion);
}
return configuredObject;
}
}
/**
* 具体某个应用程序模块,需要ConfiguredObject对象实例才能运行
* @author ASCE1885
*
*/
public class Application {
private ConfiguredObject configuredObject;
public void run(ConfiguredObject co) {
configuredObject = co;
System.out.println("MajorVersion is : " + co.getMajorVersion());
System.out.println("MinorVersion is : " + co.getMinorVersion());
}
}
/**
* Main模块
* @author ASCE1885
*
*/
public class Main {
public static void main(String[] args) {
//创建Builder对象
Builder builder = new Builder();
ConfiguredObject co = builder.createConfiguredObject("R3","C02");
//创建Application对象
Application app = new Application();
app.run(co);
}
}
2)引入抽象工厂方法
上面的方法中,应用程序并不知道对象co何时被创建,但是有些情况下,应用程序也要负责确定创建对象的时机,例如在某订单处理系统中,应用程序必须创建LineItem实体并添加到Order对象。这种情况下,我们可以应用抽象工厂模式让应用程序自行控制何时创建LineItem,同时构造的细节隔离于应用程序代码之外。如图所示,从箭头的方向可知,应用程序OrderProcessing与如何构建LineItem的细节是分离开的,它只拥有抽象工厂方法的接口,具体细节是由main这边的LineItemFactoryImplementation实现的。但应用程序能完全控制LineItem实体何时创建,甚至能传递应用特定的构造器参数。
简单实现代码如下:
/**
* LineItem实体
* @author ASCE1885
*
*/
public class LineItem {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public LineItem(String name) {
this.name = name;
}
}
/**
* 抽象工厂类
* @author ASCE1885
*
*/
public interface LineItemFactory {
public LineItem makeLineItem(String name);
}
/**
* 具体工厂类
* @author ASCE1885
*
*/
public class LineItemFactoryImpl implements LineItemFactory {
private LineItem lineItem;
@Override
public LineItem makeLineItem(String name) {
if (null == lineItem) {
lineItem = new LineItem(name);
}
return lineItem;
}
}
/**
* 订单处理类,自行控制何时创建LineItem
* @author ASCE1885
*
*/
public class OrderProcessing {
private LineItem lineItem;
private LineItemFactory lineItemFactory;
public OrderProcessing(LineItemFactory lif) {
lineItemFactory = lif;
}
public void run() {
lineItem = lineItemFactory.makeLineItem("ASCE1885");
System.out.println("The name of lineItem is : " + lineItem.getName());
}
}
/**
* Main模块
* @author ASCE1885
*
*/
public class Main {
public static void main(String[] args) {
LineItemFactory lif = new LineItemFactoryImpl();
OrderProcessing op = new OrderProcessing(lif);
op.run();
}
}
3)依赖注入DI
依赖注入是控制反转IoC在依赖管理中的一种应用手段,控制反转是将第二权责从对象中分离出来,转移到另一个专注与此的对象中,从而遵循单一权责原则SRP。因为初始设置是一种全局问题,这种授权机制通常要么是main例程,要么是有特定目的的容器。
JNDI查找是DI的一种“部分”实现,如下代码片段是在JNDI中,对象请求目录服务器提供一种符合某个特定名称的“服务”:
MyService myService = (MyService)(jndiContext.lookup("NameOfMyService"));
上面代码中,调用对象jndiContext并没有控制真正返回对象的类别,但是它仍然主动分解了依赖(NameOfMyService)。
在真正的依赖注入中,类并不直接分解其依赖,而是完全被动的。类只提供可用于注入依赖的赋值器方法或者构造器参数(或两者皆有),然后在构造过程中,由DI容器来实体化所需的对象,并使用类提供的构造器参数或者赋值器方法将依赖连接到一起。至于哪个依赖对象真正得到使用,是通过配置文件或在一个有特殊目的的构造模块中编程实现的。详见Spring框架中的Java DI容器,用户在XML配置文件中定义相互关联的对象,然后在Java代码中请求特定的对象。