設計模式之單一職責原則（iOS開發，代碼用Objective-C展示）

標籤：

單一職責原則：就一個類而言，應該只有一個引起它變化的原因。

在iOS開發中，我們會很自然的給一個類添加各種各樣的功能，比如隨便寫一個簡單的應用程式，一般都會產生一個viewController類，於是我們將各種各樣的代碼，商業運算的演算法、http請求的參數(params)封裝、使用FMDB、coreData時的資料庫訪問語句都放在這個類裡面，這就意味著，無論任何需求變化，都要來修改viewController這個類，這其實是很糟糕的，維護麻煩、複用不可能、缺乏靈活性。

也許上面說的略微誇張，因為只要是稍微有iOS開發經驗的朋友都知道，在iOS開發中，是採用MVC模式的，資料處理、封裝放入model中，視圖展示、操作放入view中，而controller只是負責將model提供的資料展示到view上去。從而保證各個模組各自獨立、分工明確，容易維護。

但僅僅只是這樣還不夠，像發起http請求的代碼、各種邏輯業務的代碼、使用資料庫做離線緩衝的代碼，與view\model無關，難道就全部放在controller裡面？如果這樣做，那controller裡面代碼將非常多，且雜亂。

 

就比如說，實現一個iphone上的俄羅斯方塊遊戲（請勿完全參照圖片）：

1. 方塊形狀有不同的種類，需要代碼產生
2. 各方塊在下落的時候，應該是通過動畫下落，左右平移也應該是通過動畫，並且還需要控制每次下落一格的時間，隨著時間的推移（玩家等級的提高），格子單位時間下落的行數是不同的
3. 在什麼時間碰觸到底部的方塊？碰觸到了該怎樣停止運動？停止運動後，該不該消除這一行？等

如果將上面提到的這些全部寫在一個viewController裡面，這是非常不合理的，代碼複用性也很差。

所以需要將之分離出來，上面提到的三點，1和3是和遊戲邏輯相關的，和介面控制以及如何展示並沒有多大聯絡，為什麼要寫到ViewController裡面？正確的關係應該是這樣的，用一個類來產生不同種類的方塊，一個類來控制方塊的動畫，一個類來控制方塊的平移、碰撞等操作。這樣就可以就各個與介面邏輯無關的商務邏輯抽出來，將來如果要維護，只需要找到對應的類的功能區修改即可，而不需要改動viewController裡面的東西。

如果一個類的職責過多，就等於把這些職責耦合在一起了，一個職責的變化可能會抑制或者削弱這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受意想不到的破壞。

軟體設計要做的許多內容就是發現職責，並把那些職責相互分離。其實要去判斷是否能分離出類來，也不難，如果可以想到多於一個動機去改變一個類，那麼這個類就具有多於一個的職能，這個時候就該考慮職責分離。總的來說，在編程過程中，我們要在類的職責上多思考，做到單一職責，這樣的代碼才是易維護、易擴充、易複用、靈活多樣的。

 

設計模式之單一職責原則（iOS開發，代碼用Objective-C展示）