抽象数据类型是指一些数据以及对这些数据所进行的操作的集合
接口/API先行——Tacey
只有一个实例的类是值得怀疑的
不要创建任何并非绝对必要的继承结构
继承层次尽量限制在3层之内
如果可能，应该在所有的构造函数中初始化所有的数据成员（防御式编程实践）
优先使用深拷贝
创建类的原因
- 为现实世界中的对象建模
- 为抽象的对象建模
- 降低复杂度
- 隔离复杂度
- 隐藏实现细节
- 限制变动的影响范围
- 隐藏全局数据
- 让参数传递更顺畅
- 建立中心控制点
- 让代码更易于重用
- 为程序族做计划
- 把相关操作包装在一起
- 实现某种特定的重构
应该避免
- 避免创建万能类
- 消除无关紧要的类
- 避免用动词命名的类
超越类：包
核对表：类的质量
抽象数据类型
- 你是否把程序中的类都看作是抽象数据类型了？是否从这个角度评估它们的接口了？
抽象
- 类是否有一个中心目的
- 类的命名是否恰当？其名字是否表达了其中心目的？
- 类的接口是否展现了一致的抽象？
- 类的接口是否能够让人清除明白地知道该如何用它
- 类的接口是否足够抽象，使你能不必顾虑它是如何实现其服务的？你能把类当作做黑盒子吗？
- 类提供的服务是否足够完整，能让其他类无需动用其内部数据？
- 是否已从类中除去无关信息？
- 是否考虑过把类进一步分解为组件类？是否已尽可能将其分解？
- 在修改类时是否维持其接口的完整性
封装
- 是否把类的成员的可访问性降到最小？
- 是否避免暴露类中的数据成员
- 在编程语言所许可的范围内，类是否已尽可能地对其他类隐藏了自己的实现细节？
- 类是否避免对其使用者，包括其派生类会如何使用它做了假设？
- 类是否不依赖于其他类？他是松散耦合的吗？
继承
- 继承是否只用来建立“is a”的关系？也就是说，派生类是否遵循了LSP替换原则
- 类的文档中是否技术了其他继承策略？
- 派生类是否避免了“覆盖”不可覆盖的方法？
- 是否把公用的接口、数据和行为都放到尽可能高的继承层次中了？
- 基类中所有的数据成员是否都被定义成了private而非protected?
- 继承层次是否很浅？
跟现实相关的其他问题
- 类是否有只有大约七个或更少的数据成员？
- 是否把类直接或间接调用其他类的子程序的数量减少到最少了？
- 类是否只在绝对必要时才与其他的类相互协作？
- 是否在构造函数中初始化了所有的数据成员 （防御）
- 除非拥有经过测量的、创建浅层复本的理由，类是否都被设计为当做生成副本使用？
与语言相关的问题
- 你是否研究过所用编程语言里和类相关的各种特有问题？
要点
- 类的接口应提供一致的抽象。很多问题都是由于违背该原则而引起的。
- 类的接口应隐藏一些信息——如某个系统接口、某项设计决策、或一些实现细节
- 包含往往比继承更为可取——除非你要对is a 的关系建模
- 继承是一种有用的工具，但它却会增加复杂度，这有违于软件的首要技术使命——管理复杂度
- 类是管理复杂度的首选工具。要在设计类时给予足够的关注，才能实现这一目标