转载

架构整洁之道

2018-11-30 张子阳推荐: 4 难度: 2

又到了每年的双11，于是到京东看看有什么可买的书，就注意到了这本《架构整洁之道》。Bob大叔之前的几本书《代码整洁之道》和《敏捷软件开发》之前也都读过。这本是今年9月才出的新书，就立即买来读了。

全书近300页，分成了34篇文章，每一篇都比较短小，内容还是比较精炼的。通读过后，感觉相较于作者之前的书，没有太多新的内容，依然是以SOLID为基础，先对这些原则进行解释，再进行扩展和应用。

全书分为了6个部分，第1部分是对架构的概述：

架构（Architecture）和设计（Design）是一回事儿，架构既包含高层架构信息也应包含底层设计细节。

软件架构的终极目标是，用最小的人力成本来满足构建和维护系统的需求。

第2部分对三种编程范式进行了描述：结构化编程、面向对象编程、函数式编程。

结构化编程：将模块递归降解拆分为可推导的单元（函数）；不使用goto语句（破坏了程序流程）。

面向对象编程：封装、继承、多态、依赖反转。这里作者指出了像C这样的语言，也可以实现封装和继承等特性，只不过更容易出错。

函数式编程。

第3部分讲解了设计原则

SRP（单一职责原则）

任何一个软件模块都应该有且只有一个被修改的原因；任何一个软件模块都应该只对某一类行为者负责。

OCP（开闭原则）

设计良好的计算机软件应该易于扩展，同时抗拒修改。这里主要举的还是依赖反转的例子，高级组件（如业务逻辑）不因为低阶组件（如数据库）的变化而修改。

LSP（李氏替换原则）

类似于抽象类的机制，抽象类的调用方不需要知道抽象类的实现类（子类）。发现是否破坏该原则，可以查看下调用方是否有if..else..语句用于判断实现类的类型。

ISP（接口隔离原则）

减少不必要的依赖关系，任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦。

DIP（依赖反转原则）

源码依赖方向是控制流方向的反转。比如说，本来UserDomain（业务层）依赖于UserRepository（数据访问层），即UserDomain需要引用UserRepository，并且调用UserRepository中的方法。但是如果在UserDomain中加入一个IUserRepository的接口，UserDomain转为调用IUserRepository上的方法。那么UserDomain就不再需要依赖UserRepository，而UserRepository则需要依赖UserDomain。

第4部分讲述了组建构建原则

这部分实际是将上面的SOLID原则应用到了组件层面。这里提出了组件的稳定性概念。依赖关系必须要指向更稳定的方向。任何一个预期会经常变更的组件都不应该被一个难于修改的组件所依赖，否则这个多变的组件也会变得非常难以被修改。