## 第5章 软件构建中的设计 **关于设计启发的总结** ### 下面是对主要的设计中的启发式方法的总结： - 寻找现实世界的对象 - 辨别对象及其属性(数据和方法) - 确定可以对各个对象进行的操作 - 确定各个对象能对其他对象进行的操作 - 确定对象的那些部分是可见的. - 形成一致的抽象 - 封装实现细节 - 在可能的情况下继承 - 藏住秘密（信息隐藏） 两种秘密: - 隐藏复杂度: 这样就不用去应付它, 除非你要特别关注它时. - 隐藏变化源: 当变化发生时, 器影响能限定在局部范围内. 信息隐藏的障碍: - 信息过度分散? - 循环依赖? - 把类内数据误认为全局数据? - 可以觉察的性能损耗? 信息隐藏的价值: - 具有独特的启发力？ - 它能够激发出有效的设计方案? - 找出容易变化的区域 - 找出看起来容易变化的项目? - 把容易变化的项目分离出来? - 把看起来容易变化的项目隔离开来? - 容易变化的区域: - 业务规则 - 对硬件的依赖性 - 输入和输出 - 非标准的语言特性 - 困难的设计区域和构建区域 - 状态变量 - 保持松散耦合 耦合的标准:规模,可见性,灵活性 ### 耦合的种类: - 简单数据参数耦合 - 对象参数耦合 - 简单对象耦合 - 语义上的耦合 ### 语义耦合示例: - Module1向Module2传递一个控制标志, 告诉Module2该做什么.这种方法要求Module1 对 Module2的内部工作细节有所了解, 也就是说需要了解Module2 对控制标志的使用, 如果 Module2 把这个标志定义成一种特定的数据类型(枚举或对象),还过得去; - Module2 在 Module1修改了某个全局数据之后使用该全局数据, 这种方式就要求Module2 假设Module1对该数据作出的修改符合Module2的需要.并且Module1已经在恰当地的时间调用过. - Module1的接口要求它的Module1.initialize()子程序必须在Module1.runtime()方法之前调用. Module2知道Module1.runtime() 无论如何都会调用Module1.initialize(),所以, Module2 在实例化Module1之后并未去调用 initialize()子程序, 因为它知道调用rountime()时会调用它; - Module1把 Object传给Module2， 由于Module1知道Module2值用了Object的7个方法中的3个, 因此它只部分初始化Object–只包含那3个方法所需的数据; - Module1 把BaseObject 传给Module2， 由于Module2 知道Module1实际上只传给它是BeviedObject, 所以它把BaseObject 强制转换成DerivedObject, 并且调用DerivedObject 特有的方法. 记住 : 类和子程序是用于降低复杂度的首选和最重要的工具. 查阅常用的设计模式: - 设计模式通过吧对话提升到一个更高层次来简化交流 - 设计模式通过提升多种设计方案二带来启发性价值 - 设计模式通过吧常见解决方案的细节予以制度化以减少出错. - 探寻通用的设计模式 ### 下列的启发式方法优势也很有用： - 高内聚性 - 构造分层结构 - 严格描述类契约 - 分配职责 - 为测试而设计 - 避免失误 - 有意识地选择绑定时间 - 创建中央控制点 - 画一个图，顶一千句话 - 保持设计模块化 ### 设计中的挑战 - 设计是一个险恶的问题. - 设计是一个无章法的过程.即使他能看出清爽的成果. - 设计就是确定取舍和调整顺序的过程. - 设计受到诸多限制. - 设计是不确定的. - 设计是一个启发式的过程. - 设计是自然而然形成的. ### 关键的设计概念 - 如今的首要技术使命:管理复杂度 - 偶然的难题和本质的难题 - 管理复杂度的重要性 - 如何应对复杂度 ### 理想的设计特征 - 最小的复杂度 - 易于维护 - 松散耦合 - 可扩展性 - 可重用性 - 高扇入 - 低扇出 - 精简性 - 层次性 - 标准技术 ### 设计的层次 - 软件系统(1层) - 分解成为子系统 - 常用的子系统 - 业务规则 - 用户界面 - 数据库的访问 - 对系统的依赖性 - 分解成类(或者包,3层) - 分解为子程序(第4层) - 子程序内部设计(第5层) ### 中文要点 - 软件的首要技术使命就是管理复杂度。以简单性作为努力目标的设计方案对此最有帮助。 - 简单性可以通过两种方式来获取：一是减少在同一时间所关注的本质性复杂度的量，二是避免生成不必要的偶然的复杂度。 - 设计是一种启发式的过程。固执于某一种单一方法会损害创新能力，从而损害你的程序。 - 好的设计都是迭代的。你尝试设计的可能性越多，你的最终设计方案就会变得越好。 - 信息隐藏是个非常有价值的概念。通过询问“我应该隐藏些什么？”能够解决很多困难的设计问题。 - 很多有用有趣的、关于设计的信息存在于本书之外。这里所给出的观点只是对这些有价值资源的一点提示而已。 ### English Key Points： - Software’s Primary Technical Imperative is managing complexity. This is accomplished primarily through a design focus on simplicity. - Simplicity is achieved in two general ways: minimizing the amount of essential complexity that anyone’s brain has to deal with at any one time and keeping accidental complexity from proliferating needlessly. - Design is heuristic. Dogmatic adherence to any single methodology hurts creativity and hurts your programs. - Good design is iterative; the more design possibilities you try, the better your final design will be. - Information hiding is a particularly valuable concept. Asking, “What should I hide?” settles many difficult design issue. - Lots of useful, interesting information on design is available outside this book. The perspectives presented here are just the tip of the iceberg.