序

《代码大全》堪称编程界的经典，之前一直被同行推荐，直到最近才得以阅读实践，目前简单读了一些章节，也有在做读书笔记，所以在这也想简单分享给大家。

这本书已经经历了快一个世纪，却经久不衰，被翻译成了多种语言，至今很多设计理念来悄悄地影响我们的程序设计。原本我只是一个喜欢读应用类书籍的人，最近被这本书着实开启了新板块的大门。

此书的每一页都是真知灼见，每一行文字都来自数年的编程实践总结，必须是软件设计成功的理念引导。

套用某位程序员的话：

开始编程的时候，读的不知所云；
敲了一年代码之后，读的如饮甘泉，醍醐灌顶，如获独孤九剑一般；
敲了五年代码之后，读的吹毛求疵，鸡蛋里面挑骨头说，这里过时了，这里不合理......
现在敲了十年代码了，再次去翻，不觉叹息，方知经典永不褪色。

下面是目前的读书笔记。

第 1 章：欢迎进入软件构建的世界

第 2 章：用隐喻来更充分地理解软件开发

第 3 章：三思而后行：前期准备

第 4 章：关键的 “构建” 决策

第 5 章：软件构建中的设计

5.1 设计中的挑战

• 设计是一个险恶的问题；
• 设计是个了无章法的过程 => 直到你没时间做了为止。
• 设计就是确定取舍和调整顺序的过程。
• 设计受诸多限制。
• 设计是不确定的。
• 设计是一个启发式过程。
• 设计是自然而然形成的。
  几乎所有的系统都在其开发的起始阶段经历某种程度的设计变更，而当它们进入到后续版本中都会进行更大的改变。软件的性质决定了这些改变在多大程度上是有益且可被接受的。

5.2 关键的设计概念

软件的首要技术使命：管理复杂度。

• 将整个系统拆解为多个子系统；
• 保持子程序的短小精悍：从问题的领域着手，而不是从底层实现细节入手去编写程序。
• 写出容易让人理解的代码；
  如何应对复杂度
  高代价、低效率的设计一般来源于：
• 用复杂的方法解决简单的问题；
• 用简单但错误的方法解决复杂的问题；
• 用不恰当的复杂方法解决复杂的问题；
  解决方法：
• 把任何人在同一时间需要处理的本质复杂度的量降到最小；
• 不要让偶然性的复杂度无畏地快速增长；
  理想的设计特征
• 最小的复杂度；
• 易于维护；
• 松散耦合；
• 可拓展性；
• 可重用性；
• 高扇入：让大量的类使用某个特定的类。
• 低扇出：一个类里少量或适中地使用其他类。
• 可移植性。
• 精简性。
• 层次性。

第 6 章：可以工作的类

6.1 类的基础：抽象数据类型 ADTs

定义：指一些数据以及对这些数据所进行的操作的集合。
使用 ADT 的益处：

• 可以隐藏实现细节；
• 改动不会影响到整个程序；
• 让接口提供更多信息；
• 更容易提高性能；
• 让程序的正确性显而易见；
• 程序更具自我说明性；
• 无须在程序内到处传递数据；
• 你可以像在现实世界中那样操作实体，而不用在底层实现上操作它；

6.2 良好的类接口

6.2.1 良好的封装：

• 尽可能地限制类和成员的可访问性；
• 不要公开暴露成员数据；
• 避免把私用的实现细节放在类的接口中；
• 不要对类的使用者做出任何假设；
• 避免使用友元类；（友元类是 C++ 中的概念，可以访问其他类的私有成员）
• 不要因为一个子程序里仅使用公共子程序，就把它归为公开接口；
• 让阅读代码比编写代码更方便；
• 要格外警惕从语义上破坏封装性；
• 留意过于紧密的耦合关系；

6.3 有关设计和实现的问题

• 警惕超过约 7 个数据成员的类；
• 让类中子程序的数量尽可能的少；
• 禁止隐式地产生你不需要的成员函数和运算符；
• 减少类中所调用的不同子程序的数量；
• 对其他类的子程序的间接调用尽可能的少；
• 一般来说，应尽可能减少类和类之间相互合作的范围，尽量让下面这几个数字最小：
• 所实例化的对象的种类；
• 在被实例化对象上直接调用的不同子程序的数量；
• 调用由其他对象返回的对象的子程序的数量；

6.4 创建类的原因

• 为现实世界中的对象建模；
• 为抽象的对象建模；
• 降低复杂度；
• 隔离复杂度；
• 隐藏实现细节；
• 限制变动的影响范围；
• 隐藏全局数据，尽可能通过方法来对数据进行访问或修改；
• 让参数传递更顺畅；
• 建立中心控制点；
• 让代码更易于重用；
• 为程序族做计划：把某些预料到可能会改的抽离到单独的类中；
• 把相关操作包装在一起；
• 实现某种特定的重构；
• 避免创建万能类；
• 消除无关紧要的类；
• 避免用动词命名的类：只有行为而没有数据的类往往不是一个真正的类；

第 7 章：高质量的子程序

7.1 为什么要创建子程序？

• 降低复杂度，让每段代码都具有单一职责；
• 引入中间、易懂的抽象；
• 避免代码重复；
• 支持子类化；
• 隐藏顺序；
• 隐藏指针操作；
• 提高可移植性；
• 简化复杂的布尔判断：把一切复杂的判断放入单独的函数中；
• 改善性能：性能一次优化，能遍布到所有调用点；
• 确保所有的子程序最小；

7.2 在子程序上设计

内聚性主要是让每一个子程序去做最单一的事情，比如单位换算，我们可能很多地方会使用，把其计算方式抽离出来，这就是一个实现内聚性的展现。

7.3 要起一个好的子程序名字

• 描述子程序所做的所有事情；
• 避免使用无意义、模糊或表述不清的动词；
• 不要仅通过数字来形成不同的子程序名字：比如 part1,part2;
• 根据需要确定子程序名字长度：通过最佳为 9 - 15 个字符；
• 给函数命名时要对返回值有所描述；
• 给过程起名时使用语气强烈的动词加宾语的形式，比如 printDocument()，checkOrderInfo() 等，在面向对象的语言中，最好通过多态而不用加对象：比如 document.print()，orderInfo.check()；

• 准确适用对仗词：列举常用对仗词组：

  
  
• 为常用操作确定命名规则；

7.4 子程序可以写多长？

理论上，一般子程序保持在 50-150 行为宜。

7.5 如何使用子程序参数

• 不要把子程序的参数作为工作变量：即在子程序最好不要去修改输入参数的值；
• 把子程序的参数限定在 7 个以内；