一、原件架構(gòu)的原則

軟件架構(gòu)的七大原則如下：

1. 開閉原則
2. 依賴倒置原則
3. 單一職責(zé)原則
4. 接口隔離原則
5. 迪米特法則（最小知道原則）
6. 里氏替換原則
7. 合成/聚合復(fù)用原則

image.png

1.開閉原則

對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。

說的是,在設(shè)計(jì)一個(gè)模塊的時(shí)候,應(yīng)當(dāng)使這個(gè)模塊可以在不被修改的前提下被擴(kuò)展.
換言之,應(yīng)當(dāng)可以在不必修改源代碼的情況下改變這個(gè)模塊的行為，在保持系統(tǒng)一定穩(wěn)定性的基礎(chǔ)上，對(duì)系統(tǒng)進(jìn)行擴(kuò)展。

例如：一般軟件功能的升級(jí)就需要符合開閉原則，即不去修改原來的代碼，而是去增加新功能。

2. 依賴倒置原則

實(shí)現(xiàn)盡量依賴抽象，不依賴具體實(shí)現(xiàn)。
該原則有以下三點(diǎn)說明：

• 1、高層模塊不應(yīng)該依賴于底層模塊，兩者都應(yīng)該依賴于抽象。
• 2、抽象不應(yīng)該依賴于細(xì)節(jié)，即具體實(shí)現(xiàn)類。
• 3、細(xì)節(jié)應(yīng)該依賴于抽象。

這樣帶來的好處，可以減少類與類之間的耦合性，提高系統(tǒng)的穩(wěn)定性，提高代碼的可讀性和可維護(hù)性，并且可以降低修改程序所造成的的風(fēng)險(xiǎn)。

這就是我們通常說的面向接口編程。

3. 單一職責(zé)原則

對(duì)于一個(gè)類而言，應(yīng)該僅存在一個(gè)可以引起類變化的原因。

這條原則從字面意思來說就是：一個(gè)類、接口、方法職責(zé)盡量單一。這樣我們就能很好的進(jìn)行解耦，后期的需求變更和維護(hù)不會(huì)互相受影響，能夠降低類的復(fù)雜度，提高可讀性。

4. 接口隔離原則

客戶端不應(yīng)該依賴它不需要的接口，類之間的依賴關(guān)系應(yīng)該建立在最小的接口上。
這個(gè)原則指導(dǎo)我們?cè)谠O(shè)計(jì)接口時(shí)應(yīng)當(dāng)注意以下幾點(diǎn)：

• 1、一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口之上。
• 2、建立單一接口，不要建立功能繁多的總接口。
• 3、盡量細(xì)化接口，接口中的方法盡量少（不是越少越好，一定要適度）。

該原則符合高內(nèi)聚低耦合的設(shè)計(jì)思想，可以使類具有很好的可讀性、可擴(kuò)展性和可維護(hù)性。

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

一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象保持最少的了解，盡量降低類與類之間的耦合。

由于每個(gè)類盡量減少對(duì)其他類的依賴，因此，很容易使得系統(tǒng)的功能模塊功能獨(dú)立，相互之間不存在（或很少有）依賴關(guān)系。迪米特法則不希望類之間建立直接的聯(lián)系。如果有真的需要建立聯(lián)系的，也希望能通過他的友元類來轉(zhuǎn)達(dá)。

迪米特原則主要強(qiáng)調(diào)只和朋友交流，不和陌生人說話。出現(xiàn)在成員變量、方法的輸入、輸出參數(shù)中的類都可以稱之為成員朋友類，而出現(xiàn)在方法體內(nèi)部的類不屬于朋友類 。

6. 里氏替換原則

一個(gè)軟件實(shí)體如果適用一個(gè)父類的話，那一定是適用于其子類，所有引用父類的地方必須能透明地使用其子類的對(duì)象，子類對(duì)象能夠替換父類對(duì)象，而程序邏輯不變。

我們總結(jié)一下：子類可以擴(kuò)展父類的功能，但不能改變父類原有的功能。

• 1、子類可以實(shí)現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法。
• 2、子類中可以增加自己特有的方法。
• 3、當(dāng)子類的方法重載父類的方法時(shí)，方法的前置條件（即方法的輸入/入?yún)ⅲ┮雀割惙椒ǖ妮斎雲(yún)?shù)更寬松。
• 4、當(dāng)子類的方法實(shí)現(xiàn)父類的方法時(shí)（重寫/重載或?qū)崿F(xiàn)抽象方法），方法的后置條件（即方法的輸出/返回值）要比父類更嚴(yán)格或相等。

使用里氏替換原則有以下優(yōu)點(diǎn)：

• 1、約束繼承泛濫，開閉原則的一種體現(xiàn)。
• 2、加強(qiáng)程序的健壯性，同時(shí)變更時(shí)也可以做到非常好的兼容性，提高程序的維護(hù)性、擴(kuò)展性。降低需求變更時(shí)引入的風(fēng)險(xiǎn) 。

7. 合成/聚合復(fù)用原則

盡量使用對(duì)象組合(has-a)/聚合(contanis-a)，而不是繼承關(guān)系達(dá)到軟件復(fù)用的目的。

換句話說，就是在一個(gè)新的對(duì)象里面使用一些已有的對(duì)象，使之成為新對(duì)象的一部分，新的對(duì)象通過這些對(duì)象的委派達(dá)到復(fù)用已有功能的目的。

該原則可以使系統(tǒng)更加靈活，降低類與類之間的耦合度，一個(gè)類的變化對(duì)其他類造成的影響相對(duì)較少。

二、MVC架構(gòu)

image.png

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

• Model：數(shù)據(jù)層，讀寫數(shù)據(jù)，保存 App 狀態(tài)。
• View：頁面層，和用戶交互，向用戶顯示頁面，反饋用戶行為。
• ViewController： 邏輯層，更新數(shù)據(jù)，或者頁面，處理業(yè)務(wù)邏輯。

MVC可以幫助你很好的將數(shù)據(jù)，頁面，邏輯的代碼分離開來。使得每一層相對(duì)獨(dú)立。這樣你就能夠?qū)⒁恍┛蓮?fù)用的功能抽離出來，化繁為簡。只不過，一旦 App 的交互變復(fù)雜，你就會(huì)發(fā)現(xiàn) ViewController 將變得十分臃腫。大量代碼被添加到控制器中，使得控制器負(fù)擔(dān)過重。

此處特別說明：如果只是為了解決VC中代碼臃腫的短板，把VC中的邏輯代碼按功能模塊使用分類（category）進(jìn)行拆分，只保留必要的調(diào)用接口能有效的降低VC中代碼臃腫的問題。

作為一個(gè)開發(fā)者，有一個(gè)學(xué)習(xí)的氛圍跟一個(gè)交流圈子特別重要，這是我的iOS交流圈: 不管你是小白還是大牛歡迎入駐??！
分享內(nèi)容包括逆向安防、算法、架構(gòu)設(shè)計(jì)、多線程，網(wǎng)絡(luò)進(jìn)階，還有底層、音視頻、Flutter等等......
自己根據(jù)梳理網(wǎng)絡(luò)來的的開發(fā)經(jīng)驗(yàn)總結(jié)的學(xué)習(xí)方法，無償分享給大家。需要的話都可以自行來獲取下載。
+裙：196800191、 或者是+ WX（XiAZHiGardenia）免費(fèi)獲??！ 獲取面試資料 簡歷模板 一起交流技術(shù)

三、MVVM架構(gòu)

image.png

MVVM是Model-View-ViewModel的簡寫，是由MVP（Model-View-Presenter）模式與WPF結(jié)合的應(yīng)用方式時(shí)發(fā)展演變過來的一種新型架構(gòu)框架。

MVVM層架結(jié)果如下：

• Model： 數(shù)據(jù)層，讀寫數(shù)據(jù)，保存 App 狀態(tài)。
• View：頁面層，提供用戶輸入行為，并且顯示輸出狀態(tài)。
• ViewModel 邏輯層，它將用戶輸入行為，轉(zhuǎn)換成輸出狀態(tài)。
• ViewController：主要負(fù)責(zé)數(shù)據(jù)綁定。

這里其實(shí)叫MVVM-C架構(gòu)更合適。

ViewModel 是邏輯層，而控制器只需要負(fù)責(zé)數(shù)據(jù)綁定。如此一來控制器的負(fù)擔(dān)就減輕了許多。并且ViewModel與控制器以及頁面相獨(dú)立。那么，你就可以跨平臺(tái)使用它。你也可以很容易地測(cè)試它。

MVVM模式使用的是數(shù)據(jù)綁定基礎(chǔ)架構(gòu)，這是MVVM設(shè)計(jì)模式的核心，在使用中，利用雙向綁定技術(shù)，使得 Model 變化時(shí)，ViewModel 會(huì)自動(dòng)更新，而 ViewModel 變化時(shí)，View 也會(huì)自動(dòng)變化。ViewModel包含所有由UI特定的接口和屬性，并有一個(gè) ViewModel 的視圖的綁定屬性，當(dāng)綁定的屬性變化時(shí)，View會(huì)自動(dòng)更新視圖，所以可以把更新視圖的邏輯放到ViewModel中，減少了Controller的代碼，iOS實(shí)現(xiàn)這種綁定可以使用 通知 和 KVO。

ViewModel其實(shí)相當(dāng)于一個(gè)黑盒子，接收輸入，經(jīng)過內(nèi)部業(yè)務(wù)邏輯處理產(chǎn)出結(jié)果。

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

四、 總結(jié)

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

不管我們選擇何種架構(gòu)模式，我們都是朝著代碼的可擴(kuò)展性、可維護(hù)性、復(fù)用性、可讀性去的。我們最終的目的都是為了降低代碼的耦合性，方便后續(xù)的修改、擴(kuò)展和維護(hù)。

MVVM模式與MVC模式最大的特點(diǎn)并不是降低了VC中代碼的臃腫，而是MVMM架構(gòu)模式把業(yè)務(wù)邏輯統(tǒng)一到了VM中處理，方便單元測(cè)試和自動(dòng)化測(cè)試。

我們?cè)趯?shí)際開發(fā)中一定要根據(jù)我們的實(shí)際情況來選擇架構(gòu)模式，不要一味地追新，適合自己當(dāng)下業(yè)務(wù)的架構(gòu)模式才是好的架構(gòu)模式，不要畫虎不成反類犬。

以上只是個(gè)人見解，如有不同見解，還望不吝賜教。

參考引用

軟件架構(gòu)的七大原則

RxSwift中MVVM的介紹