面向可维护性的构造技术知识点总结

知识点概要：

• 软件维护和演化
• 可维护性指标
• 模块化设计和模块化原则
• 面向对象设计原则：SOLID

• 语法驱动的构造

　　——语法和解析器
　　——正则表达式（regexp）

一、软件维护和演化

　　软件维护指修复错误、改善性能。在设计与开发阶段就要考虑将来的可维护性。

　　软件演化指对软件进行持续的更新，软件的大部分成本来自于维护阶段。

二、可维护性目标

一些常用的可维护性指标：

　　圈复杂度：衡量代码的结构复杂性。它是通过计算程序流中不同代码路径的数量来创建的。一个具有复杂控制流的程序将需要更多的测试来实现良好的代码覆盖率，并且维护性较差。

　　代码行数：高代码行数可能代表代码试图完成太多工作，应进行拆分，也会更难维护。

　　可维护性指数：计算一个介于0和100之间的索引值，该值表示代码维护的相对容易程度。

　　继承的层次数

　　类之间的耦合度

　　单元测试的覆盖度

三、模块化设计和模块化原则

　　模块化关注：高内聚、低耦合、分离关注点、信息隐藏

　　评估模块性的五个标准：可分解性、可组合性、可理解性、可持续性--发生变化时受影响范围最小、出现异常之后的保护--出现异常后受影响范围最小

　　模块设计的五个规则：直接映射、尽可能少的接口、尽可能小的接口、显式接口、信息隐藏

四、面向对象设计原则：SOLID

1、单一责任原则（SRP）

　　不应该有多于1个原因让你的ADT发生变化，否则就拆分开；一个类，一个责任。这是最简单的原则，却是最难做好的原则。

　　

2、开放/封闭原则（OCP）

　　对扩展性的开放（可扩展，能满足新变化）、对修改的封闭（自身代码不应被修改）。利用抽象技术可以很好的解决

　　

3、Liskov替换原则（LSP）

　　与前面章节的LSP原则相似，不再赘述

4、接口隔离原则（ISP）

　　不能强迫客户端依赖于它们不需要的接口，只提供必需的接口，客户端只访问自己所需要的端口

　　

5、依赖置转原则（DIP）

　　抽象的模块不应依赖于具体的模块，具体应依赖于抽象　　

　　

换句话说：delegation的时候，要通过interface建立联系，而非具体子类

五、语法驱动的构造

　　正则语法：简化之后可以表达为一个产生式而不包含任何非终止节点