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