模块化方案（二）——介绍

spiny方案 vs 接口方案

我们先看看这个spiny框架的思想和使用，先看下图：

spiny.png

模块化分组的时候，它其实是在我们之前那种分组的基础上，加上一个module，Router，这里就是注册模块，所有需要公共出来的方法、参数、函数等信息都需要注册到这个模块中，使用方需要在这个module中找到注册信息，然后再去找到相对应的实现中去。
然后看一下另外的我们之前的方案的图

早期架构-2.png

这个spiny方案，所有module依赖的只有router，module之间的互相依赖都没有了。
到此为止，我们来比较一下这两个方案吧！
大家看之前方案的优缺点：

1. 依赖接口，弱解耦
2. 没有动态性
3. 接口依赖，编译器检查
4. 原生接口，学习开发障碍小

前面也说过了，spiny方案要比接口方案耦合度更低。接口方案缺少动态性，而spinny这里面，只要我们注册的provider和action名字不变，里面如何改动，我们都可以不用管，这样是不是有点url方案的感觉。
但是呢？大家可以看一下spiny使用，我了个大擦，是不是炒鸡无敌麻烦？而且虽然代码都是原生，大家学起来不麻烦，但是如果项目子module多，互相之间都要调用，这岂不是一个很巨大的工程？
这样看起来，spiny和接口方案可以说是五五开吧！

新鲜出炉的Loner Modularization

因为刚自己写了一个简单的框架，名字还没想好，就暂时用我的名字来命名吧！我这个方案思路其实就是在spinny基础上，简化它的注册和使用流程。那怎么简化呢？

大家都知道apt吧，那其实那么多繁琐的注册过程，我们可不可以使用apt来动态生成呢？当然可以！

那大家会问，如果调用的话，怎么办？

注册时候，我们把包名、类名，都保存起来，使用的时候，我们用反射的方法不就可以使用了吗？

这样的话，我们比接口方案的优势就明显了，唯一的一个缺点就是

• 接口依赖，编译器检查

这个问题，如果提供方改掉方法的话，使用放在编译期间是检测不到的。解决方法也是有的，就像我们项目中的接口module，里面的接口中的方法只能递增添加，不能改变。那我们也在Loner中定义，所有提供方的方法，只能递增增加，不能改变。

git地址：
LonerModularization

代码还没完善，也没传到jcenter上，后面会慢慢完善。