软件构造-面向可维护性的软件构造

一、软件维护和演化
二、可维护性的度量
三、模块化设计和模块化原则
评价模块化效果的指标
模块化设计的五个规则
耦合和内聚
四、OO设计原则：SOLID
五、OO设计原则：GRASP
一、软件维护和演化
什么是软件维护
在软件发布后，修改软件以修正错误 和提升性能。

运维工程师
修复代码后
测试所做的修改、回归测试、记录变化
除了修复问题，修改中不能引入新的故障，最大的问题：修改后没有足够的文档记录和测试
几种软件维护类型
纠正性维护、适应性维护、完善性维护、预防性维护

软件演化
软件演化：对软件进行持续的更新
软件的大部分成本来自于维护阶段
维护不只是运维工程师的工作
软件维护不仅仅是运维工程师的工作，而是从设计和开发阶段就开始了
设计和开发者需要考虑软件未来的变化和扩展
设计方案的“easy to change”
这也就是我们说的软件构造的可维护性、可扩展性和灵活性。
面向可维护性的软件构造的例子
模块化、OO设计原则、OO设计模式、基于状态的构造技术、表驱动的构造技术、基于语法的构造技术

二、可维护性的度量
圈/环复杂度：不同代码独立路径的数量。测试时要将所有独立路径覆盖到。这里有一篇很好的讲解环形复杂度的博客：点此查看
  代码行数：代码行数越多一般说明复杂度越高。但是目前已经是一个非常粗略的判断标准了。
  当然，现在对于可维护性的度量，现在已有可维护性指数了，但是公式复杂，考虑了很多的指标。
  另外还有一些不可量化的指标：例如继承的层次数(越深越不好)，类之间的耦合度(越低越好，总之就是一个类的修改最好不会对其他类产生影响)，单元测试的覆盖度(覆盖度越高越好)。

三、模块化设计和模块化原则
评价模块化效果的指标
我们可以从以下五个方面评价模块化设计是否比较好：
  (1). 可分解性：模块是不是可以分解成多个更小的相互独立的模块，如果可以的话，分解成多个更小的模块更符合模块化设计原则，也就是分而治之的思想。
  (2). 可组合性：可以很容易的将模块之间组合起来形成一整个大的模块(也就是说明了模块之间尽量相互独立)。
  (3). 可理解性：其实就是自己设计出的模块自己非常好理解。
  (4). 可持续性：小的变化只会影响模块的一小部分，不会影响这个系统。例如统一接入模式——模块提供的所有服务应该通过统一标识提供，可以提高可持续性。
  (5). 出现异常之后的保护：运行时出现不正常时尽量把异常局限于小范围内，例如出现问题就抛出异常。

模块化设计的五个规则
直接映射、尽可能少的接口、尽可能少的接口、显式接口、信息隐藏
1、直接映射
模块的结构与现实世界中问题领域的结构保持一致
受影响的评价标准：可持续性，可分解性
2、尽可能少的接口
模块应尽可能少的与其他模块通讯
受影响的评价标准：可持续性、保护性、可理解性、可组合性
”不要对太多人讲话…”
3、尽可能小的接口
如果两个模块通讯，那么它们应交换尽可能 少的信息
受影响的评价标准：可持续性、保护性”不要讲太多…”
4、显式接口
当A与B通讯时，应明显的发生在A与B的接口之间
受影响的评价标准：可分解性、可组合性、可持续性、 可理解性
5、 信息隐藏：经常发生变化的部分应该在底层，也就是隐藏在抽象接口的后面(接口在上层)。

耦合和内聚
耦合
耦合是模块之间依赖性的度量。 如果一个模块中的更改可能需要更改另一个模块，则两个模块之间存在依赖关系。通常由接口数量和接口复杂度来评价。
内聚
内聚是衡量模块的方法或职责的相关程度。
内聚和耦合
最佳的设计模式是高内聚、低耦合。

四、OO设计原则：SOLID
SOLID：五类设计原则
SOLID是指如下五个原则：

A.单一责任原则(SRP)
  内容：ADT中不应该有超过一个原因让其变化，否则就应该拆分开。也就是：一个类，一个责任。
  总的来说，这其实就是让我们把“多功能”的类去拆成“单功能”的类。但一般说来，如果我们的代码比较少，也不需要有频繁的改动，那不必强制遵守这条原则，但这条原则在软件很大且需要频繁的时候，会特别有用，不遵守很有可能是的可扩展性和性能这两方面的大幅度降低。
B.开放/封闭原则（OCP）
OCP对扩展是开放的 ，对修改是封闭的，应通过继承和组合改变/扩展功能。模块的行为应是可扩展的，从而该模块可表现出新的行为以满足需求的变化，但模块自身的代码是不应被修改的；扩展模块行为的一般途径是修改模块的内部实现；如果一个模块不能被修改，那么它通常被认为是具有固定的行为。
关键的解决方案：抽象技术
C.Liskov替换原则(LSP)
之前博客已经进行一个详细的介绍LSP讲解
D.接口隔离原则(ISP)
  内容：不能强迫客户端依赖于它们不需要的接口，只提供必需的接口。
  也就是说，接口要高内聚和精炼，不贪图接口中方法很多。这样类也可以很舒服的按照自己需求实现对应的接口。
E.依赖转置原则（DIP）
抽象的模块不应依赖于具体的模块，具体应依赖于抽象。或者说高层模块不应该依赖于低层模块,二者都应该依赖于抽象，抽象不应该依赖于实现细节,实现细节应该依赖于抽象。面向接口编程而不是面向应用编程。这样明显对可复用性和可扩展性都有很大的提升。

小结

五、OO设计原则：GRASP
GRASP是General Responsibility Assignment Software Patterns (principles)的首字母缩写，意思是通用责任分配软件模式 （原则），是关于如何为“类”和“对象”指派“职责”的一系列原则。
什么是责任
主要分为两种：掌握和操作
责任和方法
（1）控制器（Controller）
问题：谁负责处理系统输入事件？
解决方案：将系统输入事件处理由统一的外观控制器类负责，某个用例的场景控制由用例控制器负责。
控制器类本身负责收发工作，具体执行通过委托机制进行指派。

（2）信息专家（Information Expert）
问题：将责任分配给对象的一般原则是什么？
解决方案：拥有信息的类负责相应的责任。

（3）创建器（Creator）
问题：谁应该负责创建某个类的新实例？
解决方案：如果出现以下情况，B类有责任创建A类实例：
B聚合或“包含”A对象
B紧密使用A对象
B具有A的初始化数据
B是A对象的创建者

（4）低耦合（Low Coupling）
问题：如何支持低依赖性，低变化影响和增加重用？
解决方案：分配责任，使耦合保持低水平。

（5）高内聚（High Cohesion）
问题：如何保持复杂性可管理？
解决方案：分配责任，使凝聚力保持高水平。

（6）间接（Indirection）
问题：在哪里分配责任，避免直接耦合两个（或更多）的东西？ 如何解耦对象以便支持低耦合并且重用潜力仍然更高？
解决方案：将责任分配给中间对象，以避免直接耦合。

（7）多态性（Polymorphism）
问题：如何根据类型处理替代方案？ 如何创建可插拔的软件组件？
解决方案：当相关的替代或行为因类型（类）而异时，使用多态操作将行为的责任分配给行为变化的类型。

（8）防止变异（Protected variations）
问题：如何使对象或系统的内部不稳定性不会对其他元素产生不良影响？
解决方案：确定将会发生的变化，分配责任以创建稳定的接口。

（9）纯虚构（Pure fabrication）
问题：无法依靠专家模式实现高内聚和低耦合时该怎么办？
解决方案：设计虚构的类实现高内聚低耦合和复用。