c山龙隐秀

oc的nsnumber严格来说是抽象工厂 返回的是具体的工厂类

iOS设计模式（1）简单工厂模式

设计模式系列文章 《iOS设计模式（2）工厂模式》《iOS设计模式（3）适配器模式》《iOS设计模式（4）抽象工厂模式》《iOS设计模式（5）策略模式》《iOS设计模式（6）...

leehoo

8881 13 73

c山龙隐秀

好评 介绍的很清晰

iOS设计模式（3）适配器模式

设计模式系列文章 《iOS设计模式（1）简单工厂模式》《iOS设计模式（2）工厂模式》《iOS设计模式（4）抽象工厂模式》《iOS设计模式（5）策略模式》《iOS设计模式（6...

leehoo

7789 9 32

c山龙隐秀

推荐一些我个人认为非常经典，值得关注的博客。 OneV's Den 大家尊称为喵神 @onevcat 的博客。对 Swift 技术在国内的推广做了很大的贡献。 Limboy’...

c山龙隐秀 ·

去Model化在我的设计中，有三种实现方式，字典流、reformer、Virtual Record。这三种方式其实是对应了架构中数据交换的三种不同场景：直接数据交换、多对一数据交换、一对多数据交换。

所以并没有哪一种是主要的，reformer方式也并不是主要的。

你的情况其实是多对一场景（多种数据展示在一个地方），适用reformer。其实从文章里看，你的helper就在扮演reformer的角色，只不过你的helper其实完全是可以直接输出Cell的，而不应该输出符合某个protocol的Model。

reformer在我的设计中，它本质上就只是一个protocol，意思也就是：任何对象都可以是reformer。ViewController也可以是reformer（我有时候偷懒就会这么做😂，但这种做法不推荐），那么DataSource也可以是reformer，在你的场景中，就应该让DataSource去当reformer。

另外，事实上苹果设计的DataSource本质上其实也还是一个reformer：大家都只是protocol，而且都承担了数据直接转view的功能。reformer是数据转通用View，DataSource是数据转UITableViewCell。

所以你应该把DataSource独立出来称为一个单独对象，这个单独对象也符合reformer的protocol，符合reformer的protocol这个做法只是为了便于和你的APIManager交互，并不是为了做数据转化，真正做数据转化的是DataSource（因为DataSource本质上其实就是一个reformer）。每次APIManager取到数据的时候，直接把数据丢给DataSource，也就是reformer（此时他们已经合体，下面说DataCenter或者reforme的时候，其实说的都是这同一个对象，只不过根据场景不同叫法会换）。

当这个reformer接收到来自APIManager的数据时，直接把数据洗成Dictionary，并且把对应Cell的Idendifier洗入Dictionary中。当DataSource工作的时候，cellForRowAtIndexPath时就只要写三行就结束：

UITableViewCell *cell = [tableView dequeuexxxxxidentifier:self.dataList[indexPath.row][@"cellIdentifier"]];
return cell;

在cellWillDisplay的时候，就可以直接这么做：
UITableView <TicketCell> *ticketCell = (UITableView <TicketCell> *)cell;
[ticketCell configWithData:self.dataSource.dataList[indexPath.row]];

然后你会写三种cell，分别是价格cell、折扣cell、赠品cell，这几个cell对应不同的identifier，这几个cell都conform TicketCell这个protocol，这个protocol里面只有一个方法：configWithData。这几个cell针对configWithData的实现就是拆包dictionary然后展示。

由于reformer在收到数据的时候已经洗好了identifier，所以DataSource生成的Cell就一定能和数据对应得上。

所实现这个功能并不需要你这篇文章写得这么复杂，我的方案里也完全没有一个Model。另外有一点我要指出，其实你只是把Model范型了一下再扔出去，这严格来讲其实并不符合去model化。我来说一下原因：去model化的松耦合不光体现在数据和View上，还体现在模块之间的松耦合上。当有model的时候，我们如果要复用某个模块到别的地方，那就不得不把Model的声明带上，这个Model的声明很有可能在另一个模块中，那么这时候着另一个模块就也要不得不带上，它并不能起什么作用，只是为了给Model提供声明而已。而你这里虽然并没有给Model声明具体的对象类型，但是给Model声明了一个protocol作为facade，那么在将来迁移的时候，这个protocol也要跟着被带走，虽然比直接声明Model类型要好，但仍旧是不必要的。

扯个闲话：很高兴在你这儿也看到取Model化的应用，我一直以来的架构设计思路都是去Model化的风格，业界交流时发现真正理解和能够用好的人不多，感谢你把你的设计写出来，使我能够帮助你和其他人去理解和修正去Model化设计

590bf6c23733 评论自iOS开发-去model化开发

c山龙隐秀

1. 简单功能 2. 上面表格的实现