哈工大软件构造u6

Chapter 6: Maintainability-Oriented Software Construction Approaches
面向可维护性的软件构造方法
本章面向另一个质量指标：可维护性——软件发生变化时，是否可以以很小的代价适应变化？
本节是宏观介绍：
（1）什么是软件维护；
（2）可维护性如何度量；
（3）实现高可维护性的设计原则
后面两节介绍具体的面向可维护性的构造技术

6.1 Metrics and Construction Principles
for Maintainability
可维护性的度量与构造原则
1软件维护与演进
软件维护：修复错误、改善性能
Software Entropy 软件熵
当一个系统被修改时，它的无序或熵趋于增加。
这就是所谓的软件熵。
2可维护性度量
Cyclomatic Complexity 圈复杂度
度量代码的结构复杂性。
-它是通过计算程序流中不同代码路径的数量来创建的。
-一个具有复杂控制流的程序将需要更多的测试来实现良好的代码覆盖率，并且可维护性较差。
Lines of Code 代码行数-
表示代码中的行数。
-一个非常高的计数可能表明一个类型或方法试图做太多的工作，应该被分割。
-它还可能表明类型或方法可能难以维护。
Maintainability Index (MI) 可维护性指数
计算0到100之间的索引值，该值表示维护代码的相对容易程度。
高值意味着更好的可维护性。计算依据:
-霍尔斯特德体积(HV)
-圈复杂度(CC)
-每个模块的平均代码行数(LOC)
-每个模块的评论行百分比(COM)。
Depth of Inheritance 继承的层次数-
指示扩展到类层次结构根的类定义的数目。层次结构越深，就越难理解在哪里定义或/和重新定义了特定的方法和字段。
Class Coupling 类之间的耦合度
通过参数、局部变量、返回类型、方法调用、泛型或模板实例化、基类、接口实现、在外部类型上定义的字段和属性修饰来度量与惟一类的耦合。
好的软件设计要求类型和方法应该具有高内聚性和低耦合性。
-高耦合表示设计难于重用和维护，因为它与其他类型之间存在许多相互依赖关系。
Unit test coverage单元测试的覆盖度
指示自动单元测试覆盖代码基的哪个部分。

3模块化设计与模块化原则Modular
模块化编程是一种设计技术，它强调将程序的功能分离成独立的、可互换的模块，这样每个模块都包含执行所需功能的一个方面所需的所有内容。
在结构化编程和面向对象编程中，将整个程序的代码高级分解为若干块。
Modularity
模块化。模块化意味着将一个系统划分为多个组件或模块，每个组件或模块都可以独立于系统的其他部分进行设计、实现、测试、推理和重用。
-模块化系统的对立面是一个整体系统-大的和它的所有部分纠缠在一起，相互依赖。
一个由一个非常长的main()函数组成的程序是单块的——更难理解，也更难隔离其中的bug。
-相比之下，程序分解成小函数和类则更加模块化。
(1)评价模块化的五个标准
(2)模块化设计的五条原则
(3)耦合和内聚Coupling and Cohesion
耦合是模块之间依赖关系的度量。如果一个模块中的更改可能需要另一个模块中的更改，则两个模块之间存在依赖关系。
模块间耦合程度由:
-模块间接口数量(数量)
-每个接口的复杂度(由通信类型决定)(质量)

内聚性是一个度量模块的功能或职责之间关系有多紧密的度量。
如果一个模块的所有元素都朝着同一个目标工作，那么这个模块就具有很高的内聚性。

最好的设计具有模块内部的高内聚(也称为强内聚)和模块之间的低耦合(也称为弱耦合)。

4． OO设计原则:SOLID
5 classes design principles五类设计原则
(1) Single Responsibility Principle(SRP)
单一责任原则
(2) Open/Closed Principle (OCP)
（面向变化的）开放/封闭原则
如果不修改GraphEditor，就不可能添加新形状
了解GraphEditor添加新形状非常重要
拉拔器与形状之间的紧密耦合
不使用绘图机很难测试特定的形状
应该避免If-Else/Switch-Case
(3) Liskov Substitution Principle(LSP)
Liskov替换原则
(4) Interface Segregation Principle(ISP)
接口隔离原则
(5) Dependency Inversion Principle(DIP)
依赖转置原则
高级模块不应该依赖于低级模块。
两者都应该依赖于抽象。
优点:
-形式化类契约。
-你可以根据前置和后置条件来定义一个例程的服务。
这清楚地表明了预期的结果。
尝试设计测试
-创建一个测试友好的设计
-一个测试友好的模块可能表现出其他重要的设计特征。
-例子:你可以避免循环依赖。如果必须将业务逻辑与UI代码分开测试，则可以更好地将其与UI代码隔离开来

5 OO Design Principles: GRASP
GRASP是什么模式
通用责任分配软件模式(原理)，简称为“GRASP”，由面向对象(OOP)中为类和对象分配责任的指导原则组成。
GRASP模式是一种帮助理解基本对象设计的学习工具，并以一种有方法的、合理的、可解释的方式应用设计推理。
这种理解和使用设计原则的方法基于将职责分配给类的模式。

对象的责任:与对象的义务有关
了解:
-了解私有封装数据
-了解相关物品
-了解它可以推导或计算的东西
做的事情:
-做一些事情本身，如创建一个对象或做一个计算
-在其他对象中启动动作
-控制和协调其他对象的活动。

职责是通过以下方法实现的:
makePayment意味着sales对象有责任创建
付款对象

B ABC ABCDEF A D D

6.2 Design Patterns for Maintainability
面向可维护性的设计模式
1 Creational patterns
关于如何“创建类的新实例”的模式
(1) Factory Method pattern
工厂方法模式
(2) Abstract Factory
抽象工厂模式
名称:抽象工厂(或工具包)
目的:允许独立于实现创建相关对象的族
方法:使用工厂返回可用于创建相关对象集的工厂。
适用性
-保持独立于初始化或表示的不同组件(产品)家族
-必须以相互排斥和一致的方式使用
-向客户隐瞒多个家庭的存在
——制造商独立
-应对即将到来的变化
(3) Builder
构造器模式
2 Structural patterns 结构模式
(1) Bridge
桥接模式
(2) Proxy
代理模式
(3) Composite
组合模式
3 Behavioral patterns 行为模式
(1) Observer
(2) Visitor
(3) Mediator中介
(4) Command命令
(5) Chain of responsibility职责链模式

3 High-level Considerations on Design Patterns for Reusability and Maintainability
在可重用性和可维护性方面的设计模式的高级考虑

D CD C D B C C D A ABDF

6.3 Maintainability-Oriented
Construction Techniques
面向可维护性的构造技术
学了这么多OO设计模式，不外乎都是
delegation + subtying，万变不离其宗
除了OO，还有什么其他能够提升软件可
维护性的构造技术？——本节从委派+子
类型跳出来，学习以下三个方面：
(1) 基于状态的构造技术
(2) 表驱动的构造技术
(3) 基于语法的构造技术

1 State-based construction 基于状态的构造技术
(1) Automata-based programming
基于自动机的编程
(2) State Pattern
状态模式(behavioral pattern)
(3) Memento Pattern
备忘录模式(behavioral)
2* Table-driven construction表驱动的构造技术
3 Grammar-based construction语法驱动的构造
(1) Constituents of a Grammar
(2) Operators in a Grammar
(3) Recursion in grammars
(4) Parse Trees
(5) Markdown and HTML
(6) Regular Grammars and Regular Expressions
(7) * Parsers
(8) Using regular expressions in Java正则表达式regex
(9)* Interpreter 解释器模式

D C C D B CE C C A C C

6.4 Commonality and Difference of
Design Patterns
设计模式的共性和差异