解耦的优点与缺点
优点:
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模块中。