程序设计巩固 （一）模块化与解耦

模块化与解耦

简述

本文主要讲述了在iOS开发过程中，模块化工程架构的一种组织方式，本文主要讲述基于cocoapods来做模块化的方案，详细讲述了iOS开发怎么进行模块划分的内容，主要会在以下方面做阐述：

• 为什么要做模块化
• 模块设计原则
• 模块化开发有哪些优点和缺点
• 解耦与通信

1.为什么要做模块化？

我们都知道最基本的代码设计原则：“Don’t repeat yourself!”，每一个工程都会有自己的架构，即使你是刚入门的开发者，写几天代码也会发现要把一些常用到的重复代码单独拿出来放在一个叫common的地方，实现代码复用。这样看来每个开发者其实都或多或少的做过架构方面的事情，每个团队至少有1~2个人在做这样的事情。

说道app代码架构，记得Samurai的开发者郭虹宇在群里说过这段精辟的话，引用一下:

一派是说app开发并不需要什么狗P架构，第二派说我们有自己NB的架构，第三派说只要模块化够好，每个模块应该有自己的架构。

这三个观点的出发点，我觉得也比较好理解，第一种应该是一些个人开发者，个人能力很强，经常一个人很快搞出来一个app，他的映像中不需要弄太多的框框框住自己，但是其实他也是有一套自己的架构的。第二派应该是一些公司或者大公司，有一套NB的架构对于团队的意义就比较大了，可以保证稳定迭代，保证规范和持久可维护性。第三派应该是BAT这样的有很多BU的超级公司，或者一些先进的开源开发者们，模块化能够更好的实现跨app的代码和功能的复用, 能够更好的共享资源，避免重复造轮子。

那么为什么要做模块化？已经很明显了，模块化的代码框架最屌，不信，看看苹果的框架怎么做的，你就明白了。

2. 模块设计原则

既然模块化最屌，那怎么才能做好project的模块化拆分呢，哪些代码应该被放到一个模块？这里分享一些我的经验。

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

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

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

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

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

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

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