第 5 章：软件构建中的设计
5.1 设计中的挑战
设计是一个险恶的问题；
设计是个了无章法的过程 => 直到你没时间做了为止。
设计就是确定取舍和调整顺序的过程。
设计受诸多限制。
设计是不确定的。
设计是一个启发式过程。
设计是自然而然形成的。
几乎所有的系统都在其开发的起始阶段经历某种程度的设计变更，而当它们进入到后续版本中都会进行更大的改变。软件的性质决定了这些改变在多大程度上是有益且可被接受的。
5.2 关键的设计概念
软件的首要技术使命：管理复杂度。
将整个系统拆解为多个子系统；
保持子程序的短小精悍：从问题的领域着手，而不是从底层实现细节入手去编写程序。
写出容易让人理解的代码；
如何应对复杂度
高代价、低效率的设计一般来源于：
用复杂的方法解决简单的问题；
用简单但错误的方法解决复杂的问题；
用不恰当的复杂方法解决复杂的问题；
解决方法：
把任何人在同一时间需要处理的本质复杂度的量降到最小；
不要让偶然性的复杂度无畏地快速增长；
理想的设计特征
最小的复杂度；
易于维护；
松散耦合；
可拓展性；
可重用性；
高扇入：让大量的类使用某个特定的类。
低扇出：一个类里少量或适中地使用其他类。
可移植性。
精简性。
层次性。
第 6 章：可以工作的类
6.1 类的基础：抽象数据类型 ADTs
定义：指一些数据以及对这些数据所进行的操作的集合。
使用 ADT 的益处：
可以隐藏实现细节；
改动不会影响到整个程序；
让接口提供更多信息；
更容易提高性能；
让程序的正确性显而易见；
程序更具自我说明性；
无须在程序内到处传递数据；
你可以像在现实世界中那样操作实体，而不用在底层实现上操作它；
6.2 良好的类接口
6.2.1 良好的封装：
尽可能地限制类和成员的可访问性；
不要公开暴露成员数据；
避免把私用的实现细节放在类的接口中；
不要对类的使用者做出任何假设；
避免使用友元类；（友元类是 C++ 中的概念，可以访问其他类的私有成员）
不要因为一个子程序里仅使用公共子程序，就把它归为公开接口；
让阅读代码比编写代码更方便；
要格外警惕从语义上破坏封装性；
留意过于紧密的耦合关系；
6.3 有关设计和实现的问题
警惕超过约 7 个数据成员的类；
让类中子程序的数量尽可能的少；
禁止隐式地产生你不需要的成员函数和运算符；
减少类中所调用的不同子程序的数量；
对其他类的子程序的间接调用尽可能的少；
一般来说，应尽可能减少类和类之间相互合作的范围，尽量让下面这几个数字最小：
所实例化的对象的种类；
在被实例化对象上直接调用的不同子程序的数量；
调用由其他对象返回的对象的子程序的数量；
6.4 创建类的原因
为现实世界中的对象建模；
为抽象的对象建模；
降低复杂度；
隔离复杂度；
隐藏实现细节；
限制变动的影响范围；
隐藏全局数据，尽可能通过方法来对数据进行访问或修改；
让参数传递更顺畅；
建立中心控制点；
让代码更易于重用；
为程序族做计划：把某些预料到可能会改的抽离到单独的类中；
把相关操作包装在一起；
实现某种特定的重构；
避免创建万能类；
消除无关紧要的类；
避免用动词命名的类：只有行为而没有数据的类往往不是一个真正的类；
作者：nanchen2251
链接：https://www.jianshu.com/p/02ad9e5756ea
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。