oc的nsnumber嚴格來說是抽象工廠 返回的是具體的工廠類
iOS設計模式（1）簡單工廠模式設計模式系列文章 《iOS設計模式（2）工廠模式》《iOS設計模式（3）適配器模式》《iOS設計模式（4）抽象工廠模式》《iOS設計模式（5）策略模式》《iOS設計模式（6）...
發簡信
IP屬地：浙江
-
-
好評 介紹的很清晰
iOS設計模式（3）適配器模式
設計模式系列文章 《iOS設計模式（1）簡單工廠模式》《iOS設計模式（2）工廠模式》《iOS設計模式（4）抽象工廠模式》《iOS設計模式（5）策略模式》《iOS設計模式（6...
-
iOS設計模式（3）適配器模式設計模式系列文章 《iOS設計模式（1）簡單工廠模式》《iOS設計模式（2）工廠模式》《iOS設計模式（4）抽象工廠模式》《iOS設計模式（5）策略模式》《iOS設計模式（6...
-
高質量 iOS 博客推薦
推薦一些我個人認為非常經典，值得關注的博客。 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化設計 -
