《代码整洁之道》第十一章:系统

　　由于忘记了新浪博客的密码，重置，服务器又报错。无奈，将《代码整洁之道》的读书笔记搬到博客园来。一者能继续读书计划，二者熟悉博客园的环境。

　　本章的题目是系统，可以看出是从整体和更高的层面来讲整洁。同时，作者也换了。

　　软件团队所致力的工作应该如同一个城市的运转一样，演化出恰当的抽象等级和模块，进行关注面切分及抽象层级。

　　1、将系统的构造与使用分开。

　　构造和使用是非常不一样的过程。如同一间酒店的建设和使用时完全不同的景象。建成后的酒店，在其中住宿的人看到的是整洁的建筑，覆盖着玻璃幕墙和漂亮的漆色。而起重机、升降机和安全帽都会消失无踪。

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

　　接下来，为了拥有解决主要依赖问题的全局性一贯策略，作者介绍了将对象构造的启始和设置过程从正常运行时逻辑中分离出来的几种方法：

　　①分解main

　　将全部构造过程搬迁到main或者被称之为main的模块中。应用程序对main或者构造过程一无所知。只是指望一切已齐备。

　　②工厂

　　有时应用程序也要负责确定合适创建对象。这种情况下， 我们可以使用抽象工厂模式，让应用自行控制何时创建LineItems,单构造的细节却隔离于应用程序代码之外。构建能力由工厂持有，工厂在main这一边。但应用程序能完全控制对象何时创建，并能传递特定的构造参数。

　　③依赖注入

　　依赖注入是“控制翻转”（Inversion of Control，IoC）在依赖管理中的一种应用手段。（PS：走神儿去恶补了一下IoC），有了初步认识，但是还不是很理解，需要专门再学习和练习。

 　　2、扩容

　　“一开始就做对系统”纯属神话。反之，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。这就是迭代和增量敏捷的精髓所在。

　　　软件系统与物理系统可以类比，架构可以递增式地增长，只要我们持续将关注面恰当地切分。
　　3、测试驱动系统架构

　　软件没有必要先做大设计（Big Design Up Front）。它有可能阻碍改进。这不同于建筑设计师，因为半成品的大楼不可能做根本性改动。尽管软件也有物理的一面，只要软件的架构有效切分了各个关注面，还是有可能做根本性改动的。