XMNetworking 是今天微博上看到的 南峰子 他们团队一个同学开源的一个网络框架.
这个框架是基于 AFNetworking 的再次封装, 接口简洁, 使用简单.
这引起了我的一个简单的小思考, 什么才是一个好的封装呢?
这个问题其实是个很个人的问题, 我只能说说我自己的想法.
我认为简单的封装就是把搜有的流程变成 三个步骤, 并且简化这三个步骤
配置->执行->响应
其实任何类库往小了说也就是这三个步骤, 把他们优雅非切开, 就是我对封装的理解.
我们往往希望的就是在一个地方把我需要的配置设置好, 在需要的时候去执行方法, 然后统一的得到结果,处理结果.
希望是美好的,事实是残酷的,我们往往面对的是一堆不知所云的的参数,一些不知什么时候调用的代理,还有一堆各色各样的执行方法,我觉得这个时候,我会想起来曾经听到的一个小笑话, 如何评价一个 java 程序员的好坏呢? 就是看他对 Spring 知道的有多少.... 当然,我不会 java, 就当我瞎说的吧.
那我们结合 XMNetworking 来说一下我对这三个步骤的理解
XMNetworking 一个分为三个大类 XMRequest XMCenter XMEngine, 其实这三个类也就可以简单的映射为我之前说的三个步骤, 当然不得不说 这个库的确是个很简单的类库, 如果稍微复杂一点, 也不能这么简单的分为三块.
XMRequest 对应的就是配置, XMCenter 对应的是调用和响应, XMEngine 对应的具体的执行
XMRequest 看名字我们也都知道,它代表着一个请求, 当我们发起一个请求的时候,只需要设置这个 request 的参数, 然后把它传递给 XMCenter 就大功告成了.
当然, 我希望看到的是清爽配置清单, 而不知数以百计复杂的参数. 这个又要说一个笑话, 就是如何看一个软件是否拥有设计师, 就看它的主页上是否罗列了一大堆参数设置项.
所以, 我认为在对配置进行封装的时候要把常用的参数暴露出来, 把复杂的不经常使用的参数隐藏起来.
那么我们就一定要把所有配置放在一起设置吗, 当然不是, 我们还要根据需求, 把他们再次进行区分, 并且放到合适的地方. 比如说 XMNetworking 就把全局的参数都放到了 XMCenter 中去设置.
XMCenter, 这个是一个壳, 我们通过它, 把参数传进去, 然后再通过它触发回调, 好的封装是我只需要关心壳, 而不需要必须去探寻底层的实现, 如果有一些库要求我们再上一层调用之后还要进入到下层中处理回调, 我相信是没有人愿意使用它的. 而且我想说的是 代理模式, 不得不承认 代理 在一些情景中是十分正确高效的, 但是在处理一些简单的逻辑或者说是流式/链式的逻辑的时候感觉有点复杂, 我更希望使用 callback block 来处理, 而代理呢, 我觉得更适用于处理事件的触发, 比如 tableview.
还有一点值得说的就是 XMCenter 提供的调用接口, 为了用户体验, 它提供了很多简化的接口, 这也是让人很舒服的一点, 并且考虑到使用场景提供了 单例 和 生成对象两种模式. 能够简单的应付大多数问题
XMEngine这个类相对前面的两个类就复杂的多了, 他封装了所有对 AFN 的操作, 这也就是把所有复杂的东西封装起来, 多余的就不说了.
最后还有一点说的就是, 封装难道就是仅仅把原有的方法优雅的重构一遍?当然不是, 我们往往在封装的时候还可以吧我们的一些逻辑和行为进行再次封装, 从而简化我们的操作, TTRequest 提供了两个类 XMChainRequest XMBathRequest, 我希望大家自己去看看源码, 然后自己体会一下.
总结
先说明一点, 肯定没有绝对正确的理论, 尤其是这种很个人的封装方式的讨论.
具体的解决问题的方式还要根据具体的需求来进行判断.
表面上, 让类库变得简单而优雅.
内在呢, 要把结构变得低耦合, 清晰, 可拓展
最后就是在基础功能的基础之上还要加上额外的便利功能.
这就是我对封装的不成熟的个人理解.
