项目的规模增长到一定程度之后会面临很多问题,特别是进入调整期之后,大多数需求是针对已有功能的调整和优化,功能的耦合给开发和测试带来了很多困难。
项目中比较典型的耦合有以下几种:
1.组件与环境的耦合
1-1.png
问题
:组件的显示依赖于所处的环境为其提供数据,用户对组件的操作也依赖环境去传达和执行。这导致两个问题,一是承载多个组件的环境会很臃肿,二是多个使用组件的环境都要实现管理组件的逻辑。
1-2.png
解决方法
:将组件的管理逻辑封装成管理类,这个类要解决两个问题,一是能够提供组件所需要的所有数据,二是能够执行组件相关的所有操作。
2.数据的显示与操作的耦合
2-1.png
问题
:同一条数据会映射到多种组件中,不同的操作也会对同一条数据进行不同的修改。这导致一个操作需要映射到多种组件,多个操作就会产生N*N的映射逻辑。修改某一处操作或者显示都会导致大量映射逻辑的修改,影响范围大且测试难度大。
2-2.png
解决方法
:将映射逻辑下沉,即放到数据库框架中进行。操作的结果不再去直接映射到各个组件中的数据,而是写入数据库,由数据库通知相应的组件数据变更,各个组件只根据数据库中的数据进行显示,不再接收其它地方的数据映射。
3.操作的发起与结果的耦合
3-1.png
问题
:不同的组件或者组件管理类发起同一个操作,并各自处理操作的结果。这会导致处理操作结果的逻辑冗余且可能有差异,当操作发生变动时就需要多处修改。
3-2.png
解决方法
:组件只负责发起操作,结果处理在统一的操作类中处理,包括结果的解析与写库。这样有一个额外的好处,组件发起操作一般是在主线程,因为我们不再需要对结果进行映射(也需要在主线程),我们可以在操作类中以后台线程处理结果。
4.模块健壮性耦合
4-1.png
问题
:一个模块的健壮性依赖于其它模块的健壮性,这里所说的健壮性包括模块的输入、内部逻辑与输出的健壮性。当上游模块被修改时,无法保证下游模块的健壮。
4-2.png
解决方法
:每个模块要能够独自保持自身的安全,不用因为其它模块的修改而重新进行健壮性测试。
5.模块依赖耦合
5-1.png
问题
:多个模块之间存在互相调用的关系,模块之间互相依赖,当某一模块被修改时,与该模块有调用关系的相关模块可能都需要修改与测试,也即无法确定某一模块修改的影响范围。
5-2.png
解决方法
:将模块之间的依赖关系下沉,以一个公共模块处理依赖和调用逻辑,这也是业界比较火的概念“组件化”,从软件工程理论上说这是针对接口编程而非针对实现编程。
解耦合是我们改善项目组织结构的第一步,项目实现解耦合之后会在可修改性和可测试性上有很大改善。
网友评论