第5章 软件构建中的设计
最后更新于:2022-04-01 05:01:33
## 第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.