可维护性编程(1)

可维护性的度量与构造原则

软件的维护和演化

定义：软件可维护性是指软件产品被修改的能力，修改包括纠正，改进或软件对环境，需求和功能规格说明变化的适应。
类型：纠错性，适应性，完善性，预防性。
演化：软件演化是一个程序不断调节以满足新的软件需求的过程。
演化的规律：软件质量下降，延续软件生命。
软件维护和演化的目标：提高软件的适应性，延续软件生命。

可维护性的常见度量指标

可维护性：可轻松修改软件系统或组件，以纠正故障，提高性能或其他属性，或适应变化的环境。
软件可维护性的五个子特性：
1.易分析性：软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
2.易改变性：软件产品使指定的修改可以被实现的能力，实现包括编码，设计和文档的更改。如果软件由最终用户修改，那么易改变性可能会影响易操作性。
3.稳定性：软件产品避免由于软件修改而造成意外结果的能力。
4.易测试性：软件产品使已修改软件能被确认的能力。
5.维护性的依从性：软件产品遵循与维护性相关的标准或约定的能力。

模块化设计规范

模块化编程的含义：模块化编程是一种设计技术，它强调将程序的功能分解为独立的可互换模块，以便每个模块都包含执行所需功能的一个方面。
设计规范：高内聚，低耦合。
评估模块化的五个标准：
1.可分解性：将问题分解为各个可独立解决的子问题。
2.可组合性：可容易的将模块组合起来形成新的系统。
3.可理解性：每个子模块都可被系统设计者容易的理解。
4.可持续性：小的变化将只影响一小部分模块，而不会影响整个体系结构。
5.出现异常之后的保护：运行时的不正常将局限于小范围模块内。

模块化设计的五条原则

1.直接映射：模块的结构与现实世界中问题领域的结构保持一致。
2.尽可能少的接口：模块应尽可能少的与其他模块通讯。
3.尽可能小的接口：如果两个模块通讯，那么它们应交换尽可能少的信息。
4.显示接口：当A与B通讯时，应明显的发生在A与B的接口之间。
5.信息隐藏：经常可能发生变化的设计决策应尽可能隐藏在抽象接口后面。

内聚性

又称块内联系，指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个块内各元素联系的越紧密，则它的内聚性越高。

耦合性

也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量，模块之间联系越紧密，其耦合性就越强，模块的独立性就越差。模块间耦合高低取决于模块间接口的复杂性，调用的方式及传递的信息。

SOLID原则

单一职责原则告诉我们实现类要职责单一，里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，它告诉我们要扩展开放，对修改关闭。

SRP单一责任原则

含义：需要修改某个类的时候原因有且只有一个。换句话说就是让一个类只做一种类型责任，当这个类需要承担其他类型的责任时，就需要分解这个类。
如果一个类包含了多个责任，那么将引起不良后果，引入额外的包，占据资源；导致频繁的重新配置，部署等。

OCP开放封闭原则

软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。
这个原则是诸多面向对象编程原则中最抽象，最难理解的一个。
关键解决方案：抽象技术，使用继承和组合来改变类的行为。

LSP里氏替换原则

优先使用委托而不是继承，或者说只有在确定is-a的关系时，才使用继承，因而继承总是导致紧耦合的设计。

ISP接口分离原则

含义：客户端不应依赖于它们不需要的方法，换句话说，使用多个专门的接口比使用单一的总接口总要好。
客户模块不应该依赖大的接口，应该裁剪为小的接口给客户模块使用，以减少依赖性。如java中一个类实现多个接口，不同的接口给不同的客户模块使用，而不是提供给客户模块一个大的接口。

DIP依赖转置原则

定义：
1.高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
2.抽象不应该依赖于细节，细节应该依赖于抽象。