最近一段时间，在思考如何合理的架构一个可扩展性良好的界面编程方式。这一部分的成果做成了一个叫ElementKit的库。目前功能在不断的完善中。
github地址：https://github.com/yishuiliunian/ElementKit
构建
基础框架概述
既然想偷懒，就得先看看我们之前在界面编程上面做了些什么，有哪些地方还有空间能让我们偷懒。我们写界面，在MVC的模式下面，一般我们会先建个XXViewController。然后在里面把数据的获取维护，对于界面样式和展示的管理都做了。且等一下，我们做的貌似不止这些：还有界面的维护（layout布局），还有一些子界面的构建，还有各种动画效果的处理，还有页面之间的跳转….
这些暂且都称之为职责。提到职责，很容易想起那个叫做单一职责的模式。一个类处理一个职责。而我们目前的问题是我们要创造出这个类来，那就按照职责划分吧。每个职责一个类，这样就会有一个初始的架构。但是我们还是会发现，其实有些职责可以合并，比如layout布局和自己面维护，我们可以在一个子View中处理掉。继续向上归纳，我们把所有的职责分成了两类：
1.业务逻辑
2.界面
一个是里子，一个是面子。于是创建了EKElement基类，该类是所有处理业务逻辑类的基类。起名Elemement，元素之意，即是希望它能够有化学变化的魅力，在组合中创造出新的东西。而界面则复用UIView的整套规则。
@interface EKElement : NSObject <EKActionHandler, EKUIResponseHandler>
{
Class _viewClass;
}
- (id) createResponser;
@property (nonatomic, assign, readonly) int64_t compareIdentifier;
@property (nonatomic, weak, readonly) UIResponder* uiEventPool;
@end
可以看到EKElement的属性方法和方法并不多。
- (id) createResponser;
用于获取一个新的该元素可以处理的界面类实例（可以是UIViewController，也可以是UIView）。总之一切可以响应用户输入之物皆可以。这个也就是属性变量uiEventPool。
@property (nonatomic, weak, readonly) UIResponder* uiEventPool;
希望EKElement来处理一些业务逻辑的东西，通过这个EKElement的抽象，把我们一般业务逻辑中可以复用的部分提取出来。省的下次还得再写一遍。关于这个可以看一个EKElment的子类实现EKTableElement。
我们用EKTableElement类实现了一个TableView常用的逻辑，主要是一些二维数据的维护职责。同事我们也对Cell做了类似的处理。
EKCellElement处理了一些cell会处理的常用业务逻辑。而每一种Cell都是一个独特的EKCellElement的子类去处理他独特的业务逻辑。具体可以通过下面的类图大概了解。
通过上述的处理实际上我们将EKCellElement当成了一个独立的逻辑单元，他可以独立处理一种Cell所有的展示和交互逻辑。举个使用的例子：
上图中我们可以看到三种类型的Cell:
1.完善个人信息那个Cell，YHToastCellElement
2.中间大图Cell， YHInfoMessageCellElement
3.下部多图片Cell， YHInfoMessageCellElement
这些Cell中还有着丰富的交互，下面两个Cell中：点击查看图片了，点击头像和昵称跳转了，点击右边评论跳转聊天了…，而第一个Cell还有点击后跳转页面并移除自身的交互…。
在以前的编程模式中，我们要把这些交互写在臃肿的ViewController中。而现在则是写在具体的Element中，每个Elmenent有足够的上下文信息来出来这些交互。
而上述界面完成的时候，并没有多少代码，
上图中灰色部分为框架类，里面完成了绝大多数的TableView的逻辑。而主要写的就是两种不同样式和业务逻辑的Cell（界面）和其Element（业务逻辑）。
这个地方有意思的事情就来了，我们知道在iOS开发中绝大多数的界面都是由TableView组成的。而TableView里面承载的内容千变万化，尤其是在以Feed流为主体交互的应用中，比如聊天页面和信息展示页面，里面的Cell千变万化，交互也多。而基于目前的ElementKit的方式，增加一种Feed的样式，只需要写个Element就行了，在Cell的Element里面处理几乎所有的业务逻辑，而不需要臃肿的写在ViewController里面。而一旦写好一批Cell的Element之后，如果来了一个新的页面，我们完全可以使用已有的看一下已有的Element是否能够使用（样式可以复用就复用Cell，业务逻辑可以复用就复用Element，这里写好一些常用的扩展EKInputExtention），如果可以筛选出来，放进TableElement里面就行了。就像堆积木一样，一个页面就可以堆出来了。我们所追求的复用性和扩展性在这里，有了非常不错的体现。
交互处理
在MVVM的架构实践中，很多团队喜欢配合ReactiveCocoa (RAC) 使用。我思考过这个原因，为什么：下雨天，MVVM和RAC更配偶？MVVM相对于MVC其职责划分更细，必然引入了更多的类（view-model），而任何架构都很难脱离Apple的MVC的基础，这势必延长整个数据的传递链。基于响应式思想的RAC，使用流式处理数据。这正好缩短了使用过程中，数据传递路径。可以直接将界面事件绑定到VM上，从来极大的减少开发成本。其实引入RAC是最好用方式，但是通过观察发现：在我们的APP中真正需要传递的更多的是事件，而这个事件可能被Element相关联的链条上的每一个元素响应，设计模式上类似于响应链模式。于是本着自己造轮子的作孽心态，写了一套类似于CPU中央总线机制的EventBus.
当界面上一个事件发生的时候，会将该事件跑到中央总线上，所有挂在了总线上的实例都可以接口到该消息。按照责任链的方式传递事件，并响应事件。
总结
至此，我们通过结构设计解决了基础的复用性和可扩展性问题，并通过设计了EventBus来解决了在设计的结构上的类之间的事件传递的问题。这样我们得到的一个异变的MVVM架构。
BY:yishuiliunian
