c山龍隱秀

oc的nsnumber嚴(yán)格來說是抽象工廠 返回的是具體的工廠類

iOS設(shè)計(jì)模式（1）簡單工廠模式

設(shè)計(jì)模式系列文章 《iOS設(shè)計(jì)模式（2）工廠模式》《iOS設(shè)計(jì)模式（3）適配器模式》《iOS設(shè)計(jì)模式（4）抽象工廠模式》《iOS設(shè)計(jì)模式（5）策略模式》《iOS設(shè)計(jì)模式（6）...

leehoo

8893 13 73

c山龍隱秀

好評 介紹的很清晰

iOS設(shè)計(jì)模式（3）適配器模式

設(shè)計(jì)模式系列文章 《iOS設(shè)計(jì)模式（1）簡單工廠模式》《iOS設(shè)計(jì)模式（2）工廠模式》《iOS設(shè)計(jì)模式（4）抽象工廠模式》《iOS設(shè)計(jì)模式（5）策略模式》《iOS設(shè)計(jì)模式（6...

leehoo

7858 9 32

c山龍隱秀

推薦一些我個(gè)人認(rèn)為非常經(jīng)典，值得關(guān)注的博客。 OneV's Den 大家尊稱為喵神 @onevcat 的博客肝劲。對 Swift 技術(shù)在國內(nèi)的推廣做了很大的貢獻(xiàn)顽铸。 Limboy’...

c山龍隱秀 ·

去Model化在我的設(shè)計(jì)中根资，有三種實(shí)現(xiàn)方式架专，字典流、reformer玄帕、Virtual Record部脚。這三種方式其實(shí)是對應(yīng)了架構(gòu)中數(shù)據(jù)交換的三種不同場景：直接數(shù)據(jù)交換、多對一數(shù)據(jù)交換裤纹、一對多數(shù)據(jù)交換睛低。

所以并沒有哪一種是主要的，reformer方式也并不是主要的服傍。

你的情況其實(shí)是多對一場景（多種數(shù)據(jù)展示在一個(gè)地方）钱雷，適用reformer。其實(shí)從文章里看吹零，你的helper就在扮演reformer的角色罩抗，只不過你的helper其實(shí)完全是可以直接輸出Cell的，而不應(yīng)該輸出符合某個(gè)protocol的Model灿椅。

reformer在我的設(shè)計(jì)中套蒂，它本質(zhì)上就只是一個(gè)protocol钞支，意思也就是：任何對象都可以是reformer。ViewController也可以是reformer（我有時(shí)候偷懶就會這么做??操刀，但這種做法不推薦）烁挟，那么DataSource也可以是reformer，在你的場景中骨坑，就應(yīng)該讓DataSource去當(dāng)reformer撼嗓。

另外，事實(shí)上蘋果設(shè)計(jì)的DataSource本質(zhì)上其實(shí)也還是一個(gè)reformer：大家都只是protocol欢唾，而且都承擔(dān)了數(shù)據(jù)直接轉(zhuǎn)view的功能且警。reformer是數(shù)據(jù)轉(zhuǎn)通用View，DataSource是數(shù)據(jù)轉(zhuǎn)UITableViewCell礁遣。

所以你應(yīng)該把DataSource獨(dú)立出來稱為一個(gè)單獨(dú)對象斑芜，這個(gè)單獨(dú)對象也符合reformer的protocol，符合reformer的protocol這個(gè)做法只是為了便于和你的APIManager交互祟霍，并不是為了做數(shù)據(jù)轉(zhuǎn)化杏头，真正做數(shù)據(jù)轉(zhuǎn)化的是DataSource（因?yàn)镈ataSource本質(zhì)上其實(shí)就是一個(gè)reformer）。每次APIManager取到數(shù)據(jù)的時(shí)候沸呐，直接把數(shù)據(jù)丟給DataSource大州，也就是reformer（此時(shí)他們已經(jīng)合體，下面說DataCenter或者reforme的時(shí)候垂谢，其實(shí)說的都是這同一個(gè)對象厦画，只不過根據(jù)場景不同叫法會換）。

當(dāng)這個(gè)reformer接收到來自APIManager的數(shù)據(jù)時(shí)滥朱，直接把數(shù)據(jù)洗成Dictionary根暑，并且把對應(yīng)Cell的Idendifier洗入Dictionary中。當(dāng)DataSource工作的時(shí)候徙邻，cellForRowAtIndexPath時(shí)就只要寫三行就結(jié)束：

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

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

然后你會寫三種cell，分別是價(jià)格cell缰犁、折扣cell淳地、贈品cell，這幾個(gè)cell對應(yīng)不同的identifier帅容，這幾個(gè)cell都conform TicketCell這個(gè)protocol颇象，這個(gè)protocol里面只有一個(gè)方法：configWithData。這幾個(gè)cell針對configWithData的實(shí)現(xiàn)就是拆包dictionary然后展示并徘。

由于reformer在收到數(shù)據(jù)的時(shí)候已經(jīng)洗好了identifier遣钳，所以DataSource生成的Cell就一定能和數(shù)據(jù)對應(yīng)得上。

所實(shí)現(xiàn)這個(gè)功能并不需要你這篇文章寫得這么復(fù)雜麦乞，我的方案里也完全沒有一個(gè)Model蕴茴。另外有一點(diǎn)我要指出劝评，其實(shí)你只是把Model范型了一下再扔出去，這嚴(yán)格來講其實(shí)并不符合去model化倦淀。我來說一下原因：去model化的松耦合不光體現(xiàn)在數(shù)據(jù)和View上蒋畜，還體現(xiàn)在模塊之間的松耦合上。當(dāng)有model的時(shí)候撞叽，我們?nèi)绻獜?fù)用某個(gè)模塊到別的地方姻成，那就不得不把Model的聲明帶上，這個(gè)Model的聲明很有可能在另一個(gè)模塊中能扒，那么這時(shí)候著另一個(gè)模塊就也要不得不帶上佣渴，它并不能起什么作用辫狼，只是為了給Model提供聲明而已初斑。而你這里雖然并沒有給Model聲明具體的對象類型，但是給Model聲明了一個(gè)protocol作為facade膨处，那么在將來遷移的時(shí)候见秤，這個(gè)protocol也要跟著被帶走，雖然比直接聲明Model類型要好真椿，但仍舊是不必要的鹃答。

扯個(gè)閑話：很高興在你這兒也看到取Model化的應(yīng)用，我一直以來的架構(gòu)設(shè)計(jì)思路都是去Model化的風(fēng)格突硝，業(yè)界交流時(shí)發(fā)現(xiàn)真正理解和能夠用好的人不多测摔，感謝你把你的設(shè)計(jì)寫出來，使我能夠幫助你和其他人去理解和修正去Model化設(shè)計(jì)

590bf6c23733 評論自iOS開發(fā)-去model化開發(fā)

c山龍隱秀

1. 簡單功能 2. 上面表格的實(shí)現(xiàn)