iOS開發架構，原件架構的原則

1、原件架構的原則

軟件架構的七大原則以下：面試

開閉原則
依賴倒置原則
單一職責原則
接口隔離原則
迪米特法則（最小知道原則）
里氏替換原則
合成/聚合複用原則

1.開閉原則

對擴展開放，對修改關閉。算法

說的是,在設計一個模塊的時候,應當使這個模塊能夠在不被修改的前提下被擴展. 換言之,應當能夠在沒必要修改源代碼的狀況下改變這個模塊的行爲，在保持系統必定穩定性的基礎上，對系統進行擴展。編程

例如：通常軟件功能的升級就須要符合開閉原則，即不去修改原來的代碼，而是去增長新功能。設計模式

2. 依賴倒置原則

實現儘可能依賴抽象，不依賴具體實現。 該原則有如下三點說明：markdown

一、高層模塊不該該依賴於底層模塊，二者都應該依賴於抽象。
二、抽象不該該依賴於細節，即具體實現類。
三、細節應該依賴於抽象。

這樣帶來的好處，能夠減小類與類之間的耦合性，提升系統的穩定性，提升代碼的可讀性和可維護性，而且能夠下降修改程序所形成的的風險。網絡

這就是咱們一般說的面向接口編程。多線程

3. 單一職責原則

對於一個類而言，應該僅存在一個能夠引發類變化的緣由。架構

這條原則從字面意思來講就是：一個類、接口、方法職責儘可能單一。這樣咱們就能很好的進行解耦，後期的需求變動和維護不會互相受影響，可以下降類的複雜度，提升可讀性。框架

4. 接口隔離原則

客戶端不該該依賴它不須要的接口，類之間的依賴關係應該創建在最小的接口上。 這個原則指導咱們在設計接口時應當注意如下幾點：oop

一、一個類對另外一個類的依賴應該創建在最小的接口之上。
二、創建單一接口，不要創建功能繁多的總接口。
三、儘可能細化接口，接口中的方法儘可能少（不是越少越好，必定要適度）。

該原則符合高內聚低耦合的設計思想，可使類具備很好的可讀性、可擴展性和可維護性。

5. 迪米特法則（最小知道原則）

一個對象應該對其餘對象保持最少的瞭解，儘可能下降類與類之間的耦合。

因爲每一個類儘可能減小對其餘類的依賴，所以，很容易使得系統的功能模塊功能獨立，相互之間不存在（或不多有）依賴關係。迪米特法則不但願類之間創建直接的聯繫。若是有真的須要創建聯繫的，也但願能經過他的友元類來轉達。

迪米特原則主要強調只和朋友交流，不和陌生人說話。出如今成員變量、方法的輸入、輸出參數中的類均可以稱之爲成員朋友類，而出如今方法體內部的類不屬於朋友類。

6. 里氏替換原則

一個軟件實體若是適用一個父類的話，那必定是適用於其子類，全部引用父類的地方必須能透明地使用其子類的對象，子類對象可以替換父類對象，而程序邏輯不變。

咱們總結一下：子類能夠擴展父類的功能，但不能改變父類原有的功能。

一、子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
二、子類中能夠增長本身特有的方法。
三、當子類的方法重載父類的方法時，方法的前置條件（即方法的輸入/入參）要比父類方法的輸入參數更寬鬆。
四、當子類的方法實現父類的方法時（重寫/重載或實現抽象方法），方法的後置條件（即方法的輸出/返回值）要比父類更嚴格或相等。

使用里氏替換原則有如下優勢：

一、約束繼承氾濫，開閉原則的一種體現。
二、增強程序的健壯性，同時變動時也能夠作到很是好的兼容性，提升程序的維護性、擴展性。下降需求變動時引入的風險。

7. 合成/聚合複用原則

儘可能使用對象組合(has-a)/聚合(contanis-a)，而不是繼承關係達到軟件複用的目的。

換句話說，就是在一個新的對象裏面使用一些已有的對象，使之成爲新對象的一部分，新的對象經過這些對象的委派達到複用已有功能的目的。

該原則可使系統更加靈活，下降類與類之間的耦合度，一個類的變化對其餘類形成的影響相對較少。

2、MVC架構

MVC 是 Model-View-Controller 的簡寫。MVC主要有三層：

Model：數據層，讀寫數據，保存 App 狀態。
View：頁面層，和用戶交互，向用戶顯示頁面，反饋用戶行爲。
ViewController：邏輯層，更新數據，或者頁面，處理業務邏輯。

MVC能夠幫助你很好的將數據，頁面，邏輯的代碼分離開來。使得每一層相對獨立。這樣你就可以將一些可複用的功能抽離出來，化繁爲簡。只不過，一旦 App 的交互變複雜，你就會發現 ViewController 將變得十分臃腫。大量代碼被添加到控制器中，使得控制器負擔太重。

此處特別說明：若是隻是爲了解決VC中代碼臃腫的短板，把VC中的邏輯代碼按功能模塊使用**分類（category）**進行拆分，只保留必要的調用接口能有效的下降VC中代碼臃腫的問題。

做爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是個人iOS交流圈: 無論你是小白仍是大牛歡迎入駐！！分享內容包括面試資源寶典、逆向安防、算法、架構設計、多線程，網絡進階，還有底層、音視頻、Flutter等等......

本身根據梳理網絡來的的開發經驗總結的學習方法，無償分享給你們。須要的話均可以自行來獲取下載。 +裙：196800191、或者是+ WX（XiAZHiGardenia）免費獲取！獲取面試資料簡歷模板一塊兒交流技術資源集合

3、MVVM架構

MVVM是Model-View-ViewModel的簡寫，是由MVP（Model-View-Presenter）模式與WPF結合的應用方式時發展演變過來的一種新型架構框架。

MVVM層架結果以下：

Model：數據層，讀寫數據，保存 App 狀態。
View：頁面層，提供用戶輸入行爲，而且顯示輸出狀態。
ViewModel 邏輯層，它將用戶輸入行爲，轉換成輸出狀態。
ViewController：主要負責數據綁定。

這裏其實叫MVVM-C架構更合適。

ViewModel 是邏輯層，而控制器只須要負責數據綁定。如此一來控制器的負擔就減輕了許多。而且ViewModel與控制器以及頁面相獨立。那麼，你就能夠跨平臺使用它。你也能夠很容易地測試它。

MVVM模式使用的是數據綁定基礎架構，這是MVVM設計模式的核心，在使用中，利用雙向綁定技術，使得 Model 變化時，ViewModel 會自動更新，而 ViewModel 變化時，View 也會自動變化。ViewModel包含全部由UI特定的接口和屬性，並有一個 ViewModel 的視圖的綁定屬性，當綁定的屬性變化時，View會自動更新視圖，因此能夠把更新視圖的邏輯放到ViewModel中，減小了Controller的代碼，iOS實現這種綁定可使用通知和 KVO。

ViewModel其實至關於一個黑盒子，接收輸入，通過內部業務邏輯處理產出結果。

[圖片上傳失敗...(image-da16ad-1607776281959)]

4、總結

本文主要介紹了軟件架構的七大原則、MVC架構模式、MVVM架構模式。

無論咱們選擇何種架構模式，咱們都是朝着代碼的可擴展性、可維護性、複用性、可讀性去的。咱們最終的目的都是爲了下降代碼的耦合性，方便後續的修改、擴展和維護。

MVVM模式與MVC模式最大的特色並非下降了VC中代碼的臃腫，而是MVMM架構模式把業務邏輯統一到了VM中處理，方便單元測試和自動化測試。

咱們在實際開發中必定要根據咱們的實際狀況來選擇架構模式，不要一味地追新，適合本身當下業務的架構模式纔是好的架構模式，不要畫虎不成反類犬。

以上只是我的看法，若有不一樣看法，還望不吝賜教。

參考引用

軟件架構的七大原則

RxSwift中MVVM的介紹