模块化方案(二)——介绍

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上,后面会慢慢完善。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,860评论 18 139
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 173,004评论 25 708
  • 今天来回味下组件化和模块化,这2种说法时一回事,当然还是有区别的,下面再详细说,其实很简单,只是设计范围的不同,也...
    前行的乌龟阅读 48,922评论 6 94
  • 路由是实现模块间解耦的一个有效工具。如果要进行组件化开发,路由是必不可少的一部分。目前iOS上绝大部分的路由工具都...
    黑超熊猫zuik阅读 3,959评论 8 52
  • 滴水之恩当以涌泉相报,这是小时候奶奶常在自己耳旁说过的话。是的,好久没有这样惆怅。前天晚上看到了张经理,我觉得心里...
    陪月亮摘星星阅读 379评论 10 17