clean code-代码整洁之道 阅读笔记（第十一章）

第十一章 系统

“复杂要人命,它消磨开发者的生命，让产品难以规划、构建和测试。”

 --RayOzzie，微软公司首席技术官

11.1 如何建造一个城市

        每个城市都有一组组人管理不同的部分，有些人负责全局，其他人负责细节。

        城市能运转，还因为它演化出恰当的抽象等级和模块，好让个人和他们所管理的“组件”即便在不了解全局时也能有效地运转。

11.2 将系统的构造与使用分开

        软件系统应将启始过程和启始过程之后的运行时逻辑分离开，在启始过程中构建应
用对象，也会存在互相缠结的依赖关系。

        下例就是典型的情形：延迟初始化/赋值

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

        应当将这个过程从正常的运行时逻辑中分离出来，确保拥有解决主要依赖问题的全局性一贯策略。

11.2.1 分解main

        将构造与使用分开的方法之一是将全部构造过程搬迁到main或被称之为main的模块中，设计系统的其余部分时，假设所有对象都已正确构造和设置。

11.2.2 工厂

        有时应用程序也要负责确定何时创建对象。

        比如，在某个订单处理系统中，应用程序必须创建LineItem实体，添加到Order对象。在这种情况下，我们可以使用抽象工厂模式让应用自行控制何时创建LineItems，但构造的细节却隔离于应用程序代码之外。

11.2.3 依赖注入

        有一种强大的机制可以实现分离构造与使用，那就是依赖注入（Dependency Injection，DI），控制反转（Inversion of Control，IoC）在依赖管理中的一种应用手段。控制反转将第二权责从对象中拿出来，转移到另一个专注于此的对象中，从而遵盾了单一权责原则。

        在依赖管理情景中，对象不应负责实体化对自身的依赖。反之，它应当将这份权责移交给其他"有权力"的机制，从而实现控制的反转。因为初始设置是一种全局问题题，这种授权机制通常要么是main例程，要么是有特定目的的容器。

11.3 扩容

        “一开始就做对系统”纯属神话。反之，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。这就是迭代和增量敏捷的精髓所在。测试驱动开发、重构以及它们打造出的整洁代码，在代码层面保证了这个过程的实现。

        软件系统与物理系统可以类比。它们的架构都可以递增式地增长，只要我们持续将关注面恰当地切分。

        横贯式关注面

        AOP是一种恢复横贯式关注面模块化的普适手段。

        在AOP中，被称为方面（aspect）的模块构造指明了系统中哪些点的行为会以某种方式被修改，从而支持某种特定的场景。这种说明是用某种简洁的声明或编程机制来实现的一致的。

11.4 Java代理

        Java代理适用于简单的情况，例如在单独的对象或类中包装方法调用。然而，JDK提供的动态代理仅能与接口协同工作。对于代理类，你得使用字节码操作库，比如CGLIB、ASM或Javassist。

11.5 纯 Java AOP 框架

        幸运的是，编程工具能自动处理大多数代理模板代码。在数个Java相架中，代理都是内嵌的，如SpringAOP和JBossAOP等，从而能够以纯Java代码实现面向方面编程。在Spring中，你将业务逻辑编码为旧式Java对象。POJO自扫门前雪，并不依赖于企业框架（或其他域）。因此，它在概念上更简单、更易于测试驱动。相对简单性也较易于保证正确地实现相应的用户故事，并为未来的用户故事维护和改进代码。

        使用描述性配置文件或API，你把需要的应用程序构架组合起来，包括持久化、事务、安全、缓存、恢复等横贯性问题。在许多情况下，你实际上只是指定Spring或Jboss类库，框架以对用户透明的方式处理使用Java代理或字节代码库的机制。这些声明驱动了依赖注入（DI）容器，DI容器再实体化主要对象，并按需将对象连接起来。

11.6 AspectJ 的方面

        通过方面来实现关注面切分的功能最全的工具是AspectJ语言，一种提供“一流的”将方面作为模块构造处理支持的Java扩展。在80%~90%用到方面特性的情况下，SpringAOP和JBossAOP提供的纯Java实现手段足够使用。然而，AspectJ却提供了一套用以切分关注面的丰富而强有力的工具。AspectJ的弱势在于，需要采用几种新工具，学习新语言构造和使用方式。
        藉由AspectJ近期引入的“annotation form”（使用Java5annotation定义纯Java代码的方面），新工具采用的问题大大减少。另外，Spring Framework 也有一些让拥有较少 AspectJ 经验的团队更容易组合基于annotation的方面的特性。

11.7 测试驱动系统架构

        最佳的系统架构由模块化的关注面领域组成，每个关注面均用纯Java（或其他语言）对象实现。不同的领域之间用最不具有侵害性的方面或类方面工具整合起来，这种架构能测试驱动，就像代码一样。

11.8 优化决策

        模块化和关注面切分成就了分散化管理和决策。在巨大的系统中，不管是一座城市或一个软件项目，无人能做所有决策。众所周知，最好是授权给最有资格的人。但我们常常忘记了，延迟决策至最后一刻也是好手段。

        拥有模块化关注面的POJO系统提供的敏捷能力，允许我们基于最新的知识做出优化的、时机刚好的决策，决策的复杂性也降低了。

11.9 明智使用添加了可论证价值的标准

        有了标准，就更易复用想法和组件、雇用拥有相关经验的人才、封装好点子，以及将组件连接起来。不过，创立标准的过程有时却漫长到行业等不及的程度，有些标准没能与它要服务的采用者的真实需求相结合。

11.10 系统需要领域特定语言

        领域特定语言（Domain-SpecificLanguage，DSL）是一种单独的小型脚本语言或以标准语言写就的API，领域专家可以用它编写读起来像是组织严谨的散文一般的代码。

        DSL在有效使用时能提升代码惯用法和设计模式之上的抽象层次。它允许开发者在恰当的抽象层级上直指代码的初衷。

        领域特定语言允许所有抽象层级和应用程序中的所有领域，从高级策略到底层细节，使用POJO来表达。

11.11 小结

        系统也应该是整洁的。侵害性架构会湮灭领域逻辑，冲击敏捷能力。当领域逻辑受到困扰，质量也就堪忧，因为缺陷更易隐藏，用户故事更难实现。当敏捷能力受到损害时，生产力也会降低，TDD的好处遗失殆尽。
        在所有的抽象层级上，意图都应该清晰可辨。只有在编写POJO并使用类方面的机制来无损地组合其他关注面时，这种事情才会发生。
        无论是设计系统或单独的模块，别忘了使用大概可工作的最简单方案。