一.設(shè)計(jì)模式
設(shè)計(jì)模式可以通俗的理解為實(shí)現(xiàn)/解決某些問(wèn)題，而形成的解決方案規(guī)范。增加代碼的可重用性，讓代碼能更容易理解和可靠。我們通常說(shuō)所的代理模式、迭代器模式、策略模式就屬于這一類。對(duì)各種設(shè)計(jì)模式的了解可以幫助我們更快的解決編程過(guò)程中遇到的問(wèn)題。
二.設(shè)計(jì)模式的基本規(guī)范
規(guī)范這個(gè)東西其實(shí)只是為了讓使用者能更方便的理解創(chuàng)建者定義的這個(gè)東西是什么意思而已。就和我們通常見(jiàn)的街邊路牌一樣，通俗易懂。那么我們碼農(nóng)的基本規(guī)范是什么樣呢？我們參考下蘋果在實(shí)現(xiàn)各種方法時(shí)的規(guī)范就好了。
1.命名規(guī)范
在為我們自己設(shè)計(jì)的方法提供API和命名的時(shí)候，使用者并不知道我們的內(nèi)部實(shí)現(xiàn)，所以我們就必須給我們的API提供一個(gè)簡(jiǎn)單易懂的名字和必要的注釋。讓使用者能了解基本的用途。我們通常在設(shè)計(jì)類工廠方法的時(shí)候會(huì)使用類名。我們?cè)賮?lái)參考下蘋果的TableViewDelegate
// this represents the display and behaviour of the cells.
@protocol UITableViewDelegate<NSObject, UIScrollViewDelegate>
@optional
// Display customization
- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath;
// If these methods are implemented, the above -tableView:heightForXXX calls will be deferred until views are ready to be displayed, so more expensive logic can be placed there.
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath NS_AVAILABLE_IOS(7_0);
所以在命名的時(shí)候盡量使用簡(jiǎn)潔的單詞或業(yè)內(nèi)默認(rèn)的模式讓使用者明白你是干什么的，有什么功能，解決什么問(wèn)題。同時(shí)增加必要的注釋。命名的格式參考蘋果在相關(guān)模式下的命名方式即可。這也是我們通常寫API的規(guī)范。
三.設(shè)計(jì)的基本原則
設(shè)計(jì)原則和規(guī)矩一樣，是用來(lái)規(guī)范也是用來(lái)打破的。并非所有的時(shí)候我們都需要完全準(zhǔn)守設(shè)計(jì)原則，準(zhǔn)守設(shè)計(jì)原則可以減少遇到不必要的麻煩，但是有時(shí)候如果完全準(zhǔn)守原則，你可能寸步難行。靈活變通，才是王道。
1.單一職責(zé)原則：
也就是我們常說(shuō)的一個(gè)類負(fù)責(zé)一個(gè)職責(zé)，雖然這個(gè)對(duì)于程序猿們是一個(gè)常識(shí)，但是事件經(jīng)常會(huì)發(fā)展到我們無(wú)法控制的地步。
比如剛開始的時(shí)候類T只負(fù)責(zé)一個(gè)職責(zé)P。后來(lái)由于某種原因，也許是需求變更了，需要將職責(zé)P細(xì)分為粒度更細(xì)的職責(zé)P1，P2，這時(shí)如果要使程序遵循單一職責(zé)原則，需要將類T也分解為兩個(gè)類T1和T2，分別負(fù)責(zé)P1、P2兩個(gè)職責(zé)。但是在程序已經(jīng)寫好的情況下，這樣做簡(jiǎn)直太費(fèi)時(shí)間了。所以，簡(jiǎn)單的修改類T，用它來(lái)負(fù)責(zé)兩個(gè)職責(zé)是一個(gè)比較不錯(cuò)的選擇，雖然這樣做有悖于單一職責(zé)原則。（這樣做的風(fēng)險(xiǎn)在于職責(zé)擴(kuò)散的不確定性，因?yàn)槲覀儾粫?huì)想到這個(gè)職責(zé)P，在未來(lái)可能會(huì)擴(kuò)散為P1，P2，P3，P4……Pn。所以記住，在職責(zé)擴(kuò)散到我們無(wú)法控制的程度之前，立刻對(duì)代碼進(jìn)行重構(gòu)。）
2.里氏替換原則：
這項(xiàng)原則最早是在1988年，由麻省理工學(xué)院的Barbara Liskov女士提出來(lái)的。
定義1：如果對(duì)每一個(gè)類型為 T1的對(duì)象 o1，都有類型為 T2 的對(duì)象o2，使得以 T1定義的所有程序 P 在所有的對(duì)象 o1 都代換成 o2 時(shí)，程序 P 的行為沒(méi)有發(fā)生變化，那么類型 T2 是類型 T1 的子類型。
定義2：所有引用基類的地方必須能透明地使用其子類的對(duì)象。
看完定義大致也知道這個(gè)是個(gè)和繼承相關(guān)的定義。其實(shí)就是我們通常使用繼承時(shí)子類盡量不要去修改父類的功能。這也是為什么我們?cè)诶^承父類方法進(jìn)行擴(kuò)展的時(shí)候通常都會(huì)代用super的原因。
3.依賴倒置原則：
定義：高層模塊不應(yīng)該依賴低層模塊，二者都應(yīng)該依賴其抽象；抽象不應(yīng)該依賴細(xì)節(jié)；細(xì)節(jié)應(yīng)該依賴抽象。（抽象指的是接口或者抽象類，細(xì)節(jié)就是具體的實(shí)現(xiàn)。）
在面向過(guò)程的開發(fā)，上層調(diào)用下層，上層依賴于下層，當(dāng)下層劇烈變動(dòng)時(shí)上層也要跟著變動(dòng)，這就會(huì)導(dǎo)致模塊的復(fù)用性降低而且大大提高了開發(fā)的成本。
而我們iOS是面向?qū)ο蟮拈_發(fā)，很好的解決了這個(gè)問(wèn)題，一般情況下抽象的變化概率很小，讓用戶程序依賴于抽象，實(shí)現(xiàn)的細(xì)節(jié)也依賴于抽象。即使實(shí)現(xiàn)細(xì)節(jié)不斷變動(dòng)，只要抽象不變，客戶程序就不需要變化。這大大降低了客戶程序與實(shí)現(xiàn)細(xì)節(jié)的耦合度。
簡(jiǎn)而言之就是某些可能改變的參數(shù)不要在底層的模塊進(jìn)行實(shí)現(xiàn)，而是通過(guò)傳遞參數(shù)，block塊等方式進(jìn)行傳遞。
4.接口隔離原則：
定義：客戶端不應(yīng)該依賴它不需要的接口；一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口上。
還是以蘋果的UITableViewDelegate為例，在設(shè)計(jì)時(shí)定義了部分必須實(shí)現(xiàn)的基本方法（最小接口）。那么其他的接口只需要在必要時(shí)才實(shí)現(xiàn)。而不是需要實(shí)現(xiàn)所有接口才能使用某個(gè)功能。
5.迪米特法則：
定義：一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象保持最少的了解。
問(wèn)題由來(lái)：類與類之間的關(guān)系越密切，耦合度越大，當(dāng)一個(gè)類發(fā)生改變時(shí)，對(duì)另一個(gè)類的影響也越大。
解決方案：盡量降低類與類之間的耦合。
軟件編程的總的原則：低耦合，高內(nèi)聚。無(wú)論是面向過(guò)程編程還是面向?qū)ο缶幊蹋挥惺垢鱾€(gè)模塊之間的耦合盡量的低，才能提高代碼的復(fù)用率。低耦合的優(yōu)點(diǎn)不言而喻，但是怎么樣編程才能做到低耦合呢？那正是迪米特法則要去完成的。
迪米特法則又叫最少知道原則，最早是在1987年由美國(guó)Northeastern University的Ian Holland提出。通俗的來(lái)講，就是一個(gè)類對(duì)自己依賴的類知道的越少越好。也就是說(shuō)，對(duì)于被依賴的類來(lái)說(shuō)，無(wú)論邏輯多么復(fù)雜，都盡量地的將邏輯封裝在類的內(nèi)部，對(duì)外除了提供的public方法，不對(duì)外泄漏任何信息。迪米特法則還有一個(gè)更簡(jiǎn)單的定義：只與直接的朋友通信。首先來(lái)解釋一下什么是直接的朋友：每個(gè)對(duì)象都會(huì)與其他對(duì)象有耦合關(guān)系，只要兩個(gè)對(duì)象之間有耦合關(guān)系，我們就說(shuō)這兩個(gè)對(duì)象之間是朋友關(guān)系。耦合的方式很多，依賴、關(guān)聯(lián)、組合、聚合等。其中，我們稱出現(xiàn)成員變量、方法參數(shù)、方法返回值中的類為直接的朋友，而出現(xiàn)在局部變量中的類則不是直接的朋友。也就是說(shuō)，陌生的類最好不要作為局部變量的形式出現(xiàn)在類的內(nèi)部。
6.開閉原則：
開閉原則中“開”，是指對(duì)于組件功能的擴(kuò)展是開放的，是允許對(duì)其進(jìn)行功能擴(kuò)展的；開閉原則中“閉”，是指對(duì)于原有代碼的修改是封閉的，即修改原有的代碼對(duì)外部的使用是透明的。
