序言
本來是打算寫一個系列的文章的，結果名字沒起好，就變成這樣了。設計模式和寫文章一樣并沒有什么特別的地方，只是思維方式不一樣而已。這里給大家介紹下設計模式的基本規范
前文提要：
iOS設計模式、架構模式、框架簡介之《設計模式簡介》
相關更新：
iOS設計模式之單例模式
設計模式的基本規范
規范這個東西其實只是為了讓使用者能更方便的理解創建者定義的這個東西是什么意思而已。就和我們通常見的街邊路牌一樣，通俗易懂。那么我們碼農的基本規范是什么樣呢？我們參考下蘋果在實現各種方法時的規范就好了。
一.命名規范
在為我們自己設計的方法提供API和命名的時候，使用者并不知道我們的內部實現，所以我們就必須給我們的API提供一個簡單易懂的名字和必要的注釋。讓使用者能了解基本的用途。
我們通常在設計類工廠方法的時候會使用類名。我們再來參考下蘋果的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);
所以在命名的時候盡量使用簡潔的單詞或業內默認的模式讓使用者明白你是干什么的，有什么功能，解決什么問題。同時增加必要的注釋。命名的格式參考蘋果在相關模式下的命名方式即可。這也是我們通常寫API的規范。
二.設計的基本原則
設計原則和規矩一樣，是用來規范也是用來打破的。并非所有的時候我們都需要完全準守設計原則，準守設計原則可以減少遇到不必要的麻煩，但是有時候如果完全準守原則，你可能寸步難行。靈活變通，才是王道。
1.單一職責原則：
也就是我們常說的一個類負責一個職責，雖然這個對于程序猿們是一個常識，但是事件經常會發展到我們無法控制的地步。
比如剛開始的時候類T只負責一個職責P。后來由于某種原因，也許是需求變更了，需要將職責P細分為粒度更細的職責P1，P2，這時如果要使程序遵循單一職責原則，需要將類T也分解為兩個類T1和T2，分別負責P1、P2兩個職責。但是在程序已經寫好的情況下，這樣做簡直太費時間了。所以，簡單的修改類T，用它來負責兩個職責是一個比較不錯的選擇，雖然這樣做有悖于單一職責原則。（這樣做的風險在于職責擴散的不確定性，因為我們不會想到這個職責P，在未來可能會擴散為P1，P2，P3，P4……Pn。所以記住，在職責擴散到我們無法控制的程度之前，立刻對代碼進行重構。）
2.里氏替換原則：
這項原則最早是在1988年，由麻省理工學院的Barbara Liskov女士提出來的。
定義1：如果對每一個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程序 P 在所有的對象 o1 都代換成 o2 時，程序 P 的行為沒有發生變化，那么類型 T2 是類型 T1 的子類型。
定義2：所有引用基類的地方必須能透明地使用其子類的對象。
看完定義大致也知道這個是個和繼承相關的定義。其實就是我們通常使用繼承時子類盡量不要去修改父類的功能。這也是為什么我們在繼承父類方法進行擴展的時候通常都會代用super的原因。
3.依賴倒置原則：
定義：高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。（抽象指的是接口或者抽象類，細節就是具體的實現。）
在面向過程的開發，上層調用下層，上層依賴于下層，當下層劇烈變動時上層也要跟著變動，這就會導致模塊的復用性降低而且大大提高了開發的成本。
而我們iOS是面向對象的開發，很好的解決了這個問題，一般情況下抽象的變化概率很小，讓用戶程序依賴于抽象，實現的細節也依賴于抽象。即使實現細節不斷變動，只要抽象不變，客戶程序就不需要變化。這大大降低了客戶程序與實現細節的耦合度。
簡而言之就是某些可能改變的參數不要在底層的模塊進行實現，而是通過傳遞參數，block塊等方式進行傳遞。
4.接口隔離原則：
定義：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
還是以蘋果的UITableViewDelegate為例，在設計時定義了部分必須實現的基本方法（最小接口）。那么其他的接口只需要在必要時才實現。而不是需要實現所有接口才能使用某個功能。
5.迪米特法則：
定義：一個對象應該對其他對象保持最少的了解。
問題由來：類與類之間的關系越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。
解決方案：盡量降低類與類之間的耦合。
軟件編程的總的原則：低耦合，高內聚。無論是面向過程編程還是面向對象編程，只有使各個模塊之間的耦合盡量的低，才能提高代碼的復用率。低耦合的優點不言而喻，但是怎么樣編程才能做到低耦合呢？那正是迪米特法則要去完成的。
迪米特法則又叫最少知道原則，最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講，就是一個類對自己依賴的類知道的越少越好。也就是說，對于被依賴的類來說，無論邏輯多么復雜，都盡量地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外泄漏任何信息。迪米特法則還有一個更簡單的定義：只與直接的朋友通信。首先來解釋一下什么是直接的朋友：每個對象都會與其他對象有耦合關系，只要兩個對象之間有耦合關系，我們就說這兩個對象之間是朋友關系。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變量、方法參數、方法返回值中的類為直接的朋友，而出現在局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要作為局部變量的形式出現在類的內部。
6.開閉原則：
開閉原則中“開”，是指對于組件功能的擴展是開放的，是允許對其進行功能擴展的；開閉原則中“閉”，是指對于原有代碼的修改是封閉的，即修改原有的代碼對外部的使用是透明的。
-----------我是分割線-----------
之前有簡友說我說的只是一些概念，沒錯。這些只是一些基本的概念，如果想要深入學習，當然還是必須通過買書和實踐進行系統的學習。這里只是為了給剛接觸編程的朋友提供一些基本的概念，以便找到學習的方向而已。
