推薦閱讀
一、原件架構(gòu)的原則
軟件架構(gòu)的七大原則如下：
- 開閉原則
- 依賴倒置原則
- 單一職責(zé)原則
- 接口隔離原則
- 迪米特法則（最小知道原則）
- 里氏替換原則
- 合成/聚合復(fù)用原則
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-f89f00-1627539007850)]
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中代碼臃腫的問題代兵。
三尼酿、MVVM架構(gòu)
[圖片上傳失敗...(image-461ca0-1627539007850)]
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)使用它。你也可以很容易地測試它蒸殿。
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-c9ae77-1627539007850)]
四丛版、 總結(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中處理遍膜，方便單元測試和自動(dòng)化測試。
我們?cè)趯?shí)際開發(fā)中一定要根據(jù)我們的實(shí)際情況來選擇架構(gòu)模式瓤湘，不要一味地追新瓢颅，適合自己當(dāng)下業(yè)務(wù)的架構(gòu)模式才是好的架構(gòu)模式，不要畫虎不成反類犬弛说。
以上只是個(gè)人見解挽懦，如有不同見解，還望不吝賜教木人。
參考引用
軟件架構(gòu)的七大原則
RxSwift中MVVM的介紹
xcodeiphoneiosswiftobjective-c
