【软件构造】6.1 可维护性的度量与构造原则

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

1.软件维护与演化

软件维护:修复错误、改善性能。<-- 软件开发中最困难的工作之一。
软件维护的几个类型:纠错型维护、适应型维护、完善型维护、预防型维护。
软件演化:对软件进行持续的更新。
超过90%的成本来自维护阶段。
软件维护不仅仅是运维工程师的工作,而是从设计和开发阶段就开始的工作。在设计与开发阶段就要考虑将来的可维护性,采用easy to change的设计方案。

2.可维护性的度量

可维护性、可扩展性、灵活性、可适应性、可管理性、支持性…

常用的可维护性度量方式:

1.圈复杂度:线性无关的路径条数,即合理的预防错误所需测试的最少路径条数
圈复杂度大说明程序代码可能质量低且难于测试和维护
2.代码行数:
方法的代码行数过多说明该方法执行的功能太多了,应该分解掉。
3.可维护性指数:0~100 表示维护的难度
4.继承的层次数:
层次越多越不好维护。CRP原则,尽量使用代理而不是继承。
5.类之间的耦合度:
6.单元测试的覆盖度

3.模块化设计与模块性原则

模块化编程:将程序的功能划分到独立的,可交换的模块中
模块性:将系统分解为组件(模块),每个组件(模块)都能从整个系统脱离开,独立地被设计、实现、测试、复用。

3.1 评估模块性的五个标准

1.可分解性:将问题分解为各个可独立解决的子问题
目标:使模块之间的依赖关系显式化和最小化
2.可组合性:可容易的将模块组合起来形成新的系统
目标:使模块可在不同的环境下复用
3.可理解性:每个子模块 都可被系统设计者容易的理解
4.可持续性:小的变化将只影响一小部分模块,而不会影响整个体系结构
5.出现异常之后的保护:运行时的不正常将局限于小范围模块内

3.2 模块化设计的五条规则

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

3.3 耦合与内聚

1.耦合度:衡量两个模块间的依赖关系,即其中一个模块的变化是否影响另一个
影响因素:模块间接口的数量和每个接口的复杂程度
2.内聚:衡量模块内的方法或属性的关联关系的强弱
模块之间联系越紧密,其耦合性就越强,模块之间独立性则越差
追求高内聚低耦合
在这里插入图片描述

4.面向对象的设计原则:SOLID

4.1 SRP:单一责任原则

一个类负责且只负责一类任务

4.2 OCP:开放-封闭原则

对扩展开放,对修改封闭。不修改源代码,通过扩展满足需求。
在这里插入图片描述
问题:
在这里插入图片描述

4.3 LSP:Liskov替换原则

子类型必须能够替换其基类型
派生类必须能够通过其基类的接口使用,客户端无需了解二者之间的差异

4.4 DIP:依赖转置原则

高级模块不应该依赖于低级模块,二者都应该依赖于抽象
具体应依赖于抽象
delegation的时候要通过interface建立联系,而非具体子类

4.5 ISP:接口隔离原则

只向客户端提供必需的接口
避免“fat” interfaces -->分解为多个小的接口
在这里插入图片描述
在这里插入图片描述

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值