iOS 設計模式淺析 0 – 前言

MixReality發表於2018-11-27

      小弟不才, 但又喜歡分享一些自己知道的小知識, so 斗膽寫下 iOS 常用設計模式的實用和對其的見解. 如果有錯的地方請聯絡我 QQ: 573880506, 不勝感激(畢竟程式設計師, 標點符號都用的英文狀態下的, 不喜勿噴請見諒)

1.設計模式的由來?

      針對特定的問題, 前輩總結出來的一種固定模式, 就好像你寫作文每一個段落都會空兩個格一樣.

2. 設計模式的優點

      ①. 使專案結構編變得更清晰.

      ②. 便於維護.(ps: 各設計模式優缺點會在各自專題中會進行詳細的描述)

3. 設計模式的基本原則

      ①. 開閉原則 (Open Closed Principle,OCP): 對模組擴充套件開放, 對修改關閉, 給我的感覺就是 .m 裡面的實現程式碼儘量不要去做修改, 對這個類進行擴充而不是修改. 我們正常開發時, 總遇到各式各樣的修改, 我會做的是註釋掉這段程式碼, 再重寫一份, 其實也算是變相地擴充介面.

      ②. 里氏替換原則 (Liskov Substitution Principle ,LSP): 任何類可以出現的地方,子類一定可以出現,子類跟父類可以相互替換,子類可以用父類所有的方法(下面會舉個例子). 這個比較不容易理解, 百度一搜通篇一律, 說得特別難懂, 我覺得里氏替換原則和多型有一些相類似, 都是子類繼承自父類, 子類可以擴充介面, 不同的是: 里氏替換原則儘量不要重寫父類的方法, 而多型可以重寫父類的方法.

      舉個例子: 有一個 Animals 類作為父類, Dog 類作為 Animals 類的子類, 他們都有一個方法 – (BOOL)isLikeIt; 返回值是 YES , 當你的 controller 匯入了 Animals 並呼叫了這個方法是你喜歡動物, 當你突然想換成 Dog 類時, 正常這個方法的返回值應該是 YES, 如果你的 Dog 類繼承 Animals 類時修改這個方法為 NO, 很有可能你的 controller 會死掉, 所以我們儘量不要改動父類繼承過來的方法, 而要去擴充介面才能做到賦值相容, 這也符合上面的開閉原則.

      ③. 依賴倒轉原則 (DependencyInversion Principle,DIP): 抽象不依賴於細節, 細節依賴於抽象. 父類高度抽象時, 子類才更不容易出現問題. 雜貨部 CEO 會說: “我們公司要盈利”, 廁紙經理會說: “我們要通過賣廁紙盈利”, 食品經理會說:”我們要通過賣辣條盈利”, 這才符合邏輯, 反面教材見下面的栗子:

      舉個例子: 有一個 Paper 類作為基類, 其有一個方法 – (void)used; 有一個 Money 類繼承自 Paper, 有一個 ToiletPaper(廁紙) 繼承自 Paper, 如果 Paper 類中的 used NSLog 了一句話 @”擦屁股”, Money 呼叫 used 時就會出問題, 除非你希望用錢來擦屁股.

      ④. 介面隔離原則 (InterfaceSegregationPrinciple,ISP): 介面裡面只做必要的事情, 不做其他相關的事情.

      ⑤. 合成/聚合複用原則 (Composite/ Aggregate Reuse Principle, CARP): 在一個新的物件裡面使用一些已有的物件,使之成為新物件的一部分. 用一個圖大家就明白了: 錢包類想呼叫 Money 的 used 方法, 不用繼承 Money 類, 直接匯入形成個新類即可.

                    iOS 設計模式淺析 0 – 前言

      ⑥. 最小知識原則 (Principle of Least Knowledge, PLK): 兩個類沒有彼此直接通訊, 而是使用另一個類來通訊. 我們平時用的 MVC 其實就是遵循了這一原則.

      ⑦. 單一職責原則 (Single responsibility principle,SRP): 一個類只負責一種領域, 網路請求類去做視訊渲染, 讓視訊渲染類進行網路請求

4. 23 中設計模式的分類

      ①. 建立型模式(5 種): 單例模式, 抽象工廠模式, 建造者模式, 原型模式, 工廠模式.

      ②. 併發設計模式(7 種): 代理模式, 組合模式, 橋接模式, 享元模式, 外觀模式, 裝飾模式, 介面卡模式.

      ③. 框架級別的設計模式(11 種): 觀察者模式, 訪問者模式, 中介者模式, 直譯器模式, 策略模式, 迭代器模式, 命令模式, 狀態模式, 備忘錄模式, 模板方法模式, 責任鏈模式.

5. 小結

      這裡先簡單介紹一下設計模式的相關小知識, 之後會有各設計模式單獨的文章來詳細描述各設計模式的的優缺點, demo 等相關知識.

      使用設計模式和非使用設計模式給我的感覺就像是: 鳥巢 vs 普通樓房, 雖然我總是想不起來使用設計模式, 因為我做的也是普通樓房, 當我們水平達到一定程度之時, 這些設計模式使用起來也就得心應手了.

      最後, 我想強調一句: 不要為了使用設計模式而去強行使用設計模式.

這裡是傳送門呦:

    iOS 設計模式淺析 1 – 策略

相關文章