####一.設計模式
設計模式可以通俗的理解為實現/解決某些問題，而形成的解決方案規範。增加程式碼的可重用性，讓程式碼能更容易理解和可靠。我們通常說所的代理模式、迭代器模式、策略模式就屬於這一類。對各種設計模式的瞭解可以幫助我們更快的解決程式設計過程中遇到的問題。
####二.設計模式的基本規範
規範這個東西其實只是為了讓使用者能更方便的理解建立者定義的這個東西是什麼意思而已。就和我們通常見的街邊路牌一樣，通俗易懂。那麼我們碼農的基本規範是什麼樣呢？我們參考下蘋果在實現各種方法時的規範就好了。 ######1.命名規範 在為我們自己設計的方法提供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.開閉原則：
開閉原則中“開”，是指對於元件功能的擴充套件是開放的，是允許對其進行功能擴充套件的；開閉原則中“閉”，是指對於原有程式碼的修改是封閉的，即修改原有的程式碼對外部的使用是透明的。