Clean Code 读书笔记七

clean code 之 系统

构建与使用分离

Software systems should separate the startup process, when the application objects are

constructed and the dependencies are “wired” together, from the runtime logic that takes

over after startup

public Service getService() {
    if (service == null) 
    service = new MyServiceImpl(...); // Good enough default for most cases?
    return service;
}

以上代码的问题，在于在运行时逻辑里加入了 对象的创建。

而且这个创建是临时随机的（并没有专门管理）。这里的MyServiceImpl(..)用硬编码的方式使逻辑对它依赖。如果你要测试这个方法，你就必须去处理（或者模拟）这个MyServiceImpl（…）的实现。

当然，它也有一定的合理性。但如果系统中大量存在这样的代码，就会产生问题。

We should modularize this process separately from

the normal runtime logic and we should make sure that we have a global, consistent strat-

egy for resolving our major dependencies

我们应该把构建过程模块化，是它成为全局的、不变的与主业务员逻辑隔离的构建模块。

DI

依赖注入很好的解决了上边的耦合问题。

在构造模块中，通过依赖注入，把对依赖的实例化管理交给了一个特殊的容器。

JNDI

JNDI lookup通过对查找服务目录来获取 匹配的服务。这是对DI思想的一种部分实现。

MyService myService = (MyService)(jndiContext.lookup(“NameOfMyService”));

jndiContext这个对象并不管理任何服务，但它还是灵活的返回了依赖对象MyService.

然而，DI走的更远，它没有主动获取某个依赖，而是被动的、在构建时，通过一些方式自动注入所需要的依赖。