1. 寻找现实世界中逻辑或结构一致的物体。
2. 对重复的地方进行抽象。
3. 封装实现的细节， 只提供有功能的 API。
4. 在可能的情况下继承。
5. 注意信息隐藏。
类的接口要尽可能的少暴露其内部的工作机制。其意义与 3 一样， 是为了当需求发生变化时， 可以在不改变接口的情况下改变它的实现。
6. 找出易改变的区域。
哪些项目容易改变？
1. 业务逻辑。用户需求一直在变。
2. 对硬件的依赖性。无法预测用户的设备。
3. 输入和输出。无法预测用户的输入与实际的输出。
4. 非标准的语言特性。英语和中文逻辑可不一样。
7. 困难的设计和构建区域。把糟糕的代码封装起来，保证其对系统的影响最低。
8. 状态变量。我都是用枚举。
9. 不使用 bool 值作为状态变量。 我想加个状态怎么办？
10. 使用检查模块来检查状态， 硬编码进去很累的。
11. 保持低耦合。
12. 寻找现成的设计模式。 别重复造轮子。
13. 高内聚。 一个模块就干好一件事。
14. 构造分层。把最通用的或最抽象的概念表示在层次的最上面， 而越来越详细有特定意义的概念放在最底层。让你可以把精力放在当前的层次上。
15. 把每个类的接口看作是与程序其余部分的契约。类似于， 你要是承诺提供有怎样特征的哪些数据， 我就按照契约的操作来操纵啥啥啥。
16. 分配指责。 结合 9. 每个模块分别需要干好什么事？
17. 为测试而设计。加入让你来测试这个系统， 你能够一块块地拆开检查吗？
18. 从他人的失误中得到教训。
19. 时刻意识到绑定时间。早一点赋值晚一点赋值区别大吗？指针早一点指向它或晚一点指向有区别吗？
20. 集中代码。 对于每一段有用的代码， 都只有惟一的一个地方可以看到它， 修改它。
21. 考虑用蛮力。 你要是真的会那些花里胡哨的算法也行， 不会就别装优雅乱搞。
22.画个图。 一图胜千言。
23. 每个模块都是黑盒子， 你不需要关心里面装的什么， 总之往里放东西都有想要的输出就行。