前面提到过，即使计划得最好的架构也会出现熵。通过团队磨损或未充分记录的意图，没有经验的开发人员可能会疏忽地导入似乎有用的包，不久以后，系统传入耦合的值将开始增长。
例如，将图 3 与 图 2 进行比较。您注意到架构增加的脆弱性了吗？现在不仅 dao 包直接利用第三方记帐包，而且另一个甚至不想直接使用任何记帐代码的包也引用了这两个记帐包！
图 3. 出现代码熵
试图为另一个包关闭 com.third.party.billing 包确实很具有挑战性！设想一下降低产生缺陷和中断系统各种行为方面的风险所需的测试脚手架。事实上，像这样的架构很少变更，因为它们无法支持修改。更糟糕的是，即使像对现有组件的升级这样的重要修改也会导致整个代码基中断的事情出现。
如果传入耦合是一些依赖于某个特定组件的组件的话，那么传出耦合则是某个特定组件所依赖的一些组件。可以把传出耦合看作传入耦合的逆转。
对于更改如何影响代码来说，传出耦合的引号意义与传入耦合的类似。例如，图 4 描述了 com.acme.ascp.dao 包，它具有一个值为 3 的传出耦合（或者叫做 Ce）：
图 4. dao 包中的传出耦合
如图 4 所示，com.acme.ascp.dao 包依赖于 org.apache.log4j、com.acme.ascp.util 和 com.acme.ascp.exception 组件来履行其行为契约。与传入耦合中一样，依赖性级别本身并不是什么坏事。重要的是您对耦合的了解以及耦合如何影响对相关组件的更改。
与传入耦合一样，抽象性度量在传出耦合中起作用。在 图 4 中，com.acme.ascp.dao 包完全是具体的；因此它的抽象性为 0。这表示其传出耦合包含 com.acme.ascp.dao 的组件自己会变得脆弱，因为 com.acme.ascp.dao 包与 3 个附加的包具有传出耦合。如果它们中的一个（比如说 com.acme.ascp.util）发生更改，将会在 com.acme.ascp.dao 中发生连锁反应。因为 dao 无法通过接口或抽象类隐藏注入细节，所以任何更改都可能影响它的依赖组件。
文章来源于领测软件测试网 https://www.ltesting.net/
