Clean Code学习笔记の将系统的构造与使用分开

为了软件系统在系统层级上保持整洁，需要为系统演化出恰当的抽象等级和模块。其中一个有效的方法就是将系统的构造和使用分开，因为构造和使用是非常不一样的过程。

软件系统应将启始过程和启始过程之后的运行时逻辑分离开，如果在启始过程中构建应用对象，将会存在相互缠结的依赖关系。将关注的方面分离开，是软件技艺中最古老也是最重要的设计技巧。不幸的是，多数应用程序没能做到分离处理，启始过程代码很特殊，被混杂到运行时逻辑中，下面的代码片段是著名的延迟初始化/赋值，这种处理的好处是在真正用到对象之前，无需操心这种架空构造，启始时间也会缩短，而且能够保证永远不会返回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代码中请求特定的对象。