解决耦合

解耦的优点与缺点

优点：

1、不只提高了代码的复用度，还可以实现真正的功能复用，比如同样的功能模块如果实现了自完备性，可以在多个app中复用

2、业务隔离，跨团队开发代码控制和版本风险控制的实现

3、模块化对代码的封装性、合理性都有一定的要求，提升开发同学的设计能力。

缺点：

1、入门门槛较高，新手入门需要的成本也更高

2、工具的使用成本，团队间和模块间的配合成本升高，开发效率短期会降低。

但是从长期的影响来说，带来的好处远大于坏处的，因此模块化仍然是最佳的架构选择。

好的模块应该做到如下的事情

• 越底层的模块，应该越稳定，越抽象，越具有高复用度。

  越是底层的SDK，就应该越稳定，稳定的最直观表现就是API很久都不用变化，所有的变化因子不要暴露出来，避免传递给依赖它的模块。但是要做到设计一套API很久都不用改变，那么就需要设计的时候能越抽象, 即需要我们抽象总结的能力。

  稳定性 还有一个特点就是会传递，比如 B 模块依赖了 A 模块，如果 B 模块很稳定，但是 A 模块不稳定，那么B模块也会变的不稳定了，因此下一个原则：

• 不要让稳定的模块依赖不稳定的模块， 减少依赖

  既然上面说最好不要依赖，但是我发现我的 B 模块的确依赖了 A 模块里面不可或缺的代码怎么办？ 假设依赖的代码段为 x , 现在来看x的特性, 如果X是一个可能高复用的代码段，那么无妨把x从 A 模块里面拿出来，单做成一个模块 X, 那么 B 模块依赖 X 模块就好了；灵一种情况，x是一个方法或函数，而且不太适合单做成一个模块，所以那就在B模块里面拷贝一份 x 代码就ok了，因为这样可以保证模块的 稳定性 和 自完备性.

  如果上面两种方法都不太合适，我们会在后面解耦里面讲到如何解耦

• 提升模块的复用度，自完备性有时候要优于代码复用

  什么是自完备性，就是尽可能的依赖少的模块来达到代码可复用。

  举个例子，我有个模块 Utils 里面放了大量的category工具方法等，在日常UI产品开发中，依赖这个Utils会很方便，但是我现在要写一个比较基础的模块，应该就要求复用度更高一些，这个时候需要用到Utils里面的几个方法，那这个时候还适合直接依赖Utils吗，当然不合适了，这与我们上面的设计原则相悖了啊，因此我们这时候为了这个模块的自完备性，就可以重新实现下这几个方法，而不是依赖Utils模块

• 每个模块只做好一件事情，不要让Common出现

  模块化结构是让工程结构更清晰，每个模块都只做一件事情，都有自己的一个命名，这样这个模块才能良性发展， 但是这个名字千万不要再叫Common了，试想下你有没有做过这样的事情：“哎呀，这块代码放哪都不太合适，放Common吧”， 日久以后，这个Common就变成了毒瘤，大家都依赖它，还一堆不相关的代码，这个Common模块就是我们设计原则第一点的反面教材： “非常不稳定，大量依赖，全是耦合，整个模块无法复用到其他app”, 所以删掉工程里面的Common吧，再遇到不知道放哪的代码，就要好好思考模块的设计，再不行如果具有可复用性就单建一个模块吧，为什么不可以呢？

提炼通过模块

这块其实还是讲的模块设计，一个工程的架构可能会分为很多层，然而在开发的过程中，很容易有人不注意让应该处于较底层的模块依赖了上层的模块，这种情况下应该对模块的设计进行改造实现单向依赖。

比如一个常见的普遍的例子： 一个公共的WebView模块，里面可能有WebViewController的基类，然后还有JSBridge的服务，如果设计的时候没有注意，很容易在开发过程中，这个模块被塞入大量的其他业务代码，依赖了一大堆业务模块，因为经常注册JSBridge服务需要跟业务耦合。

这个时候怎么做呢，首先我们要思考WebView模块的定位，从更全局的角度思考，每个app的架构应该都需要这样一个模块，那么我们完全可以把这个模块单独拎出来下沉为基础模块，这个时候的解耦就需要你对WebView模块做出一些设计，添加一些注册型Api，修改JSBridge的服务为可以通过注册的方式添加逻辑，这样来实现与业务解耦，业务完全可以把与自己业务相关的代码放在自己的模块里面，然后通过你设计的Api注册到WebView模块中。