iOS组件化（四）-代码解耦合

本文为博主原创文章,未经博主允许不得转载
很多的组件化文章通常是教授技术上的经验，但是在实际组件化中，尤其一个老项目进行组件化改造时，最为耗时的却是业务代码的解耦合工作。这部分工作并不高端，由于很多的代码经过不断的改动，并且改动人员水平参差不齐，解耦代码更多的时候是体力活。那么怎么高效的完成这部分无聊的工作，进入下一个高逼格的技术点呢？

一、基础代码

这部分没什么好说的，前置工作，在前三讲中应该已经做出了我们自己的基础库，之后在解耦过程中，若我们发现基础共用的代码，随时更新我们的库，在前期我们改动频繁的时候，我建议使用非正式版的方式引入基础库。

//podfile中
pod 'CSDNModuleExample', :git => 'git地址' , :branch =>'master'

这样我们不必每次发版，git更新我们拉一下pod即可。
PS：此库的原则上代码不应太多，而且复用性是非常高的，就算做一个新的完全不同的app，也可以直接拿来用的。

二、公共业务库

这部分包含公共业务部分，根据业务解耦的难度，这部分可能会很多，一般来说，推送、埋点、登录、网络请求、业务工具等随app变动的部分应放在此处。
这部分可以单独分割为多个库，比如网络请求一个库，登陆一个库，但是前期可以粗暴的都放在一起，后期再去优化，当然如果时间和业务需求都很配合，那么一开始就干净的解耦独立是的最理想的。

三、文件结构分离各业务

• 做完上述两个库，那么我们的工程中应该只剩下平台功能（App的结构）和各个业务了，当然可能不干净，我们后面随时拆即可，我们这时候就可以真正的开始解耦合业务了。
• 那么我们这时候应该创建各业务的文件夹，将相关的代码进行粗暴的分类，毕竟我们组件化的目的就是要分离各业务线，先粗暴，再细致（并不是独立工程，只是在原有的工程用不同的文件夹分类）。
• 当我们分类完成后，我们可以通过删除相关的业务，来处理编译报出的耦合问题，根据错误，在进行更为精细的分类，最终我们剩下的问题应该绝大多数是耦合问题。

四、业务解耦几点规范

接下来我们来处理业务耦合的问题，我们主要会碰上如下几个方面的问题：

1、model

model分两种情况：

• 共用=>放到业务库
• 不共用=>业务线自己存放

下决心来判断到底共不共用，如果model超出了自己model应有的功能，则需要将该功能分离出去，净化model本身。对于嵌套的model，我们也遵循是否共用的原则来进行抉择。这部分难度最小，改动复杂度也不太高。

2、view

同model，要给出是否共用的结论，然后做相应处理。
常见的问题情况：view中使用了某个业务独有的model或view，则原则上分为业务部分，其他的业务方自己提供自己的相关view。若该view共用的太严重，里面又有独有的model等，等需要考虑将model等下沉，整串葡萄都要下沉。
通过优化代码进行解耦是最优解。

3、VC

同样的，共用的下沉。
有问题的通常是无法下沉的公共VC，无法下沉的原因也多如里面的view或model为业务线独有，或者里面业务链接多个业务。
这部分问题，只能硬着头皮进行代码改造，重新设计，model部分去除数据污染，view部分独立view。

PS：VC的调用不算在解耦的内容中，这部分作为组件间相互调用的部分，我们后续会处理。

五、整理

上述工作，各个业务应该分配给各个业务的负责人，分别整理出自己业务部分的不好处理的部分，理论上，大部分都会指向相同的问题文件，而这些部分通常来说都是要进行代码改动的，加油，解决完这些难啃的骨头，我们组件化的路将变得非常光明。
这部分如果遇上很多问题，将会花费相当大的精力和时间。

六、组件调用和appDelegate改造

我们解决了上述问题后，我们将面对的是组件间的调用和appDelegate的改造，在之后我们就可以独立各业务工程了。我将在之后的章节中介绍如何进行组件间调用。