10 面向可维护性的构造技术

10.1 软件维护和演化

软件工程中的软件维护是软件产品交付后的修改，以纠正故障、提高性能或其他属性。

面向可维护性的构造的技术：

• 模块化
• OO设计原则
• OO设计模式
• 基于状态的构造技术
• 表驱动的构造技术
• 基于语法的构造技术

10.2 维修性指标

名词：

• 可维护性：“修改软件系统或组件以纠正故障、提高性能或其他属性，或适应变化的环境的容易程度”。
• 可扩展性：软件设计/实施考虑到未来的增长，并被视为对系统扩展能力和实现扩展所需努力水平的系统性度量。
• 灵活性：软件能够根据用户需求、外部技术和 会环境等进行轻松更改
• 可适应性：交互式系统（自适应系统）的一种能力，它可以根据所获取的有关其用户及其环境的信息，使其行为适应单个用户。
• 可管理性：如何高效、轻松地监控和维护软件系统，以保持系统的性能、安全性和平稳运行。
• 支持性：基于包括质量文档、诊断信息和知识渊博且可用的技术人员在内的资源，软件在部署后保持运行的有效性。

常见问题：

• 设计结构是否简单
• 模块之间是否松散耦合
• 模块内部是否高度聚合
• 是否用委托代替继承
• 是否存在许多循环
• 是否存在重复代码

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

• 圈复杂度：具有复杂控制流的程序将需要更多的测试来实现良好的代码覆盖率，并且维护性较差
• 代码行数（直观但不准确）
• 可维护性指数：计算一个介于0和100之间的索引值，该值表示维护代码的相对容易程度，越高越好维护。
• 继承的层次数
• 类之间的耦合度
• 单元测试的覆盖度：指示自动单元测试覆盖了代码库的哪些部分

代码异味：代码中出现的不好的现象

尽可能小的接口

如果两个模块通讯，那么它们应交换尽可能少的信息

对“可持续性”和“保护性”产生影响

信息隐藏

经常可能发生变化的设计决策应尽可能隐藏在抽象接口后面

每个模块的设计者必须选择模块属性的子集（暴露在外的部分）作为模块的官方信息，以供客户端模块使用。

10.3.3 低耦合和高内聚

耦合是模块之间依赖性的度量。如果一个模块的更改可能需要另一个模块的更改，则两个模块之间存在依赖关系。

模块之间的耦合程度取决于：模块之间的接口数量（数量）和每个接口的复杂性

eg：

不要刻意将功能分离，当可以预见到变化（扩展）时，再采取SRP原则。

10.4.2 （面向变化的）开/关原则（OCP）

模块的行为应是可扩展的，从而该模块可表现出新的行为以满足需求的变化。
但模块自身代码不应该被修改，扩展模块行为的一般途径是修改模块的内部实现，如果一个模块不能被修改，那它常备认为具有固定的行为。
解决方案：抽象技术，类的行为用继承和委托机制。

eg：（一个反例）

10.4.5 依赖转置原则（DIP）

高层模块不应该依赖于低层模块，二者都应该依赖于抽象。

抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

委托的时候要通过interface建立联系。

核心是使用接口来缓冲，即将接口作为参数传入类中，作为临时变量或者成员变量。将接口的实现类和调用者隔离。

其他运算符：

“选择）、“+”（至少一个）、“[]”（表示包含方括 中列出的任何字符的长度为1的字符串）、“[^]”（与前面取反）

eg：

10.5.4 分析树

将语法与字符串匹配可以生成一个解析树，该树显示字符串的各个部分如何与语法的各个部分相对应。解析树的叶子用终端标记，表示已解析的字符串部分，他们没有子节点，不能再扩大规模了。

如果我们将叶子连接在一起，我们将得到原始字符串。

eg：

eg：

eg：

字符类：

有三种匹配模式：

• Greedy ：匹配器被强制要求第一次尝试匹配时读入整个输入串，如果
  第一次尝试匹配失败，则从后往前逐个字符地回退并尝试再次匹配，直
  到匹配成功或没有字符可回退。
• Reluctant：从输入串的首(字符)位置开始，在一次尝试匹配查找中只勉
  强地读一个字符，直到尝试完整个字符串。
• Possessive: 直接匹配整个字符串，如果完全匹配就匹配成功，否则匹配
  失败。效果相当于equals()。

边界匹配器：

模式匹配在中的使用：

• ：告诉此字符串是否与给定的正则表达式匹配。调用了。
• ：围绕给定正则表达式的匹配项拆分此字符串。调用了
• ：围绕给定正则表达式的匹配项拆分此字符串。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览93645 人正在系统学习中