组件化 - 题图. PNG
项目发展到一定阶段, 业务线增多, 团队庞大, 需求变更加速, 组件化变成一种 "刚需".
组件化最早在一些大厂被提出, 如淘宝, 蘑菇街, 滴滴等, 都有各自的组件化实践,
这些实践满足了各个平台的业务发展需要, 同时也让组件化的定义越发模糊, 本文从实践角度, 梳理一下组件化过程, 供在组件化道路上迷茫的开发者参考.
本文讨论以下三个主题:
通信方案的选择
组件的划分方式, 定义组件包含的内容
最后给出一个 Demo, 演示组件的集成和消息传递.
本文主要从 iOS 技术角度出发, 兼顾跨平台实践, 其它平台可以对应参考, 其思想是贯通的.
通信方案的选择
由于组件对通信库有直接的依赖关系, 通信方案决定着组件封装形式, 讨论组件化的实践, 就需要先确定组件的通信方式, 常见的通信方式有下面三种:
通信方式 1: 协议
将方法调用抽象为协议, 调用者依赖抽象协议, 从而避免与实际被调用者紧耦合, 是面向对象的传统方法.
协议的缺点是: 维护时需要同时维护 Protocol, 接口类两部分, 影响开发效率.
通信方式 2: Target-Action
Target-Action 方式, 说白了, 就是利用了 OC 的分类特性, 在中间件中 "声明" 了每个组件各自的方法, 优点是参数传递和返回值直观, 可以强控制参数类型, 以至于在很多组件方案中都是优先选择.
强方法会造成一些问题, 举例来说, 设想在手机淘宝中, 搜索 "保温杯" 后显示一个商品列表, 其中的商品可能来自天猫也有可能来自 C 铺, 点击后分别打开天猫详情页和 C 铺详情页, 这两个商品页面差别较大, 业务流程也有差异, 应该分为两个组件, 这就需要根据跳转的商品, 区分不同平台, 并调用不同分类方法, 这部分代码无论由调用者还是中间件来处理, 都导致硬编码, 有悖组件化的初衷.
通信方式 3: Route
在 RESTful 系统中, URL 都已经不陌生, Route 方式是这种思路在 App 内的自然选择, Route 方式在传值上有限制, 不过在一个已经适配了 RESTful 的项目中, 遇到的不便实际很少, 毕竟如果一个项目已经能 web 化, 必要的模型都已经 JSON 化, 能通过 URL 传输.
在前面 "保温杯" 的例子中, 来自天猫的详情页 URL 可以是:
/tmall/detail/:itemid
来自 C 铺的详情页 URL 可以是:
/taobao/detail/:itemid
直接在 URL 上就区分了两个组件, 中间件可以直接跳转, 不需要额外的编码.
小结
通信方案是组件化的基础, 基于 URL 的 Route 方式, 形式统一, 自然区分了不同组件, 成为组件化的首选.
来源: http://www.jianshu.com/p/a0fe838c825a