恶性依赖“作恶多端”。当恶性依赖中的被依赖元素变化时，依赖它的元素也可能要跟着变化；如果后者元素又在其他依赖关系中担当“被依赖元素”的角色，可能还会引起别的元素变化；这样，影响就会传播到很大的范围。

有时候，去除恶性依赖的代价比较大；还有时候，恶性依赖在所难免；我们应当如何？答案是，不去追求完美，而是务实地用良性依赖隔离恶性依赖造成的危害。

就让我来举个极端的例子——第三方SDK。

我们要开发的是压缩工具，我们不可能漠视现有的第三方SDK的存在，它们的诱惑实在太大了。在第一个迭代周期，要支持Zip压缩格式，我们决定采用著名的Info Zip开发包。Info Zip开发包并不在我们的控制之下——它的接口可能发生改变，当我们要使用更新的包时，我们可能面临不得不改动分散在很多类中的Info Zip使用代码的问题。所以我们要隔离这个我们控制不了的变化——对，就用Adapter模式——引入一个CInfoZipAdapter类来包装Info Zip，如图21-5所示。这样，在Info Zip包升级时，我们仅需改动CInfoZipAdapter的实现就可以了。这个CInfoZipAdapter并不是一个抽象类，所以当前的设计并不满足依赖倒置原则（Dependency-Inversion Principle）推崇的“依赖于抽象”的要求；但client对CInfoZipAdapter的依赖关系是稳定的良性依赖，我们完全可以安心地远离过度设计（Over-engineering）。

谨遵敏捷宣言“经常性地交付可以工作的软件”的教诲，第一个迭代周期过后，我们发布了压缩工具的一个可以工作的版本。第二个迭代周期，我们需要使用另外一个第三方的开发包来支持新的压缩格式。显然，我们不应当让CInfoZipAdapter承担多于一个的职责，还是需要先重构。引入了接口CCompressAlgo供“外部”调用，如图21-6所示。

重构完毕，可以添加新功能了。从CCompressAlgo“接口继承”出来一个COtherAdapter来封装另一个第三方SDK，如图21-7所示。哈，基本满意：（多个）client对CCompressAlgo的良性依赖，使client的代码相当稳定；所有第三方SDK的不可控制的变化因素，都被妥善隔离。