設計模式六大原則（1）：單一職責原則
就一個類而言, 應該僅有一個引起它變化的原因. 增加功能不應該修改已有的代碼, 避免修改出錯及重復測試.
如果你能夠想到多于一個的動機去改變一個類,那么這個類就是具有多于一個的職責, 應該考慮類的職責分離.
設計模式六大原則（2）：里氏替換原則
父類型可以被子類型替換,程序行為不發(fā)生變化. 這樣父類才能真正的被復用, 而子類也能夠在父類的基礎上增加新的行為.
里氏替換原則通俗的來講就是：子類可以擴展父類的功能所意，但不能改變父類原有的功能。它包含以下4層含義：
子類可以實現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法孵构。
子類中可以增加自己特有的方法。
當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。
當子類的方法實現(xiàn)父類的抽象方法時掠拳，方法的后置條件（即方法的返回值）要比父類更嚴格蚕涤。
設計模式六大原則（3）：依賴倒置原則
高層模塊不應該依賴底層模塊. 兩個都應該依賴抽象.
抽象不應該依賴細節(jié), 細節(jié)應該依賴抽象.
依賴倒轉就是誰也不依賴誰,除了約定的接口,大家都可以靈活自如.
程序中所有的依賴關系都是終止于抽象類或者接口,那就是面向對象的設計,反之就是過程化的設計.
在實際編程中筐赔，我們一般需要做到如下3點：
低層模塊盡量都要有抽象類或接口，或者兩者都有揖铜。
變量的聲明類型盡量是抽象類或接口茴丰。
使用繼承時遵循里氏替換原則。
依賴倒置原則的核心就是要我們面向接口編程天吓，理解了面向接口編程贿肩，也就理解了依賴倒置。傳遞依賴關系有三種方式龄寞，以上的例子中使用的方法是接口傳遞汰规，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞.
設計模式六大原則（4）：接口隔離原則
定義：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上物邑。
接口隔離原則的含義是：建立單一接口溜哮，不要建立龐大臃腫的接口，盡量細化接口色解，接口中的方法盡量少茂嗓。也就是說，我們要為各個類建立專用的接口科阎，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用述吸。
很多人會覺的接口隔離原則跟之前的單一職責原則很相似，其實不然锣笨。其一蝌矛，單一職責原則原注重的是職責；而接口隔離原則注重對接口依賴的隔離错英。其二入撒，單一職責原則主要是約束類，其次才是接口和方法走趋，它針對的是程序中的實現(xiàn)和細節(jié)衅金；而接口隔離原則主要約束接口接口，主要針對抽象簿煌，針對程序整體框架的構建氮唯。
采用接口隔離原則對接口進行約束時，要注意以下幾點：
運用接口隔離原則姨伟，一定要適度惩琉，接口設計的過大或過小都不好。設計接口的時候夺荒，只有多花些時間去思考和籌劃瞒渠，才能準確地實踐這一原則良蒸。
接口盡量小，但是要有限度伍玖。對接口進行細化可以提高程序設計靈活性是不爭的事實嫩痰，但是如果過小，則會造成接口數(shù)量過多窍箍，使設計復雜化串纺。所以一定要適度。
為依賴接口的類定制服務椰棘，只暴露給調用的類它需要的方法纺棺，它不需要的方法則隱藏起來。只有專注地為一個模塊提供定制服務邪狞，才能建立最小的依賴關系祷蝌。
提高內(nèi)聚，減少對外交互帆卓。使接口用最少的方法去完成最多的事情巨朦。
運用接口隔離原則，一定要適度鳞疲，接口設計的過大或過小都不好罪郊。設計接口的時候，只有多花些時間去思考和籌劃尚洽，才能準確地實踐這一原則。
設計模式六大原則（5）：迪米特法則
定義：一個對象應該對其他對象保持最少的了解靶累。
問題由來：類與類之間的關系越密切腺毫，耦合度越大，當一個類發(fā)生改變時挣柬，對另一個類的影響也越大潮酒。
如果兩個類不必彼此直接通信,那么這兩個類就不應當發(fā)生直接的相互作用. 如果其中一個類需要調用另一個類的某一個方法的話, 可以通過第三者轉發(fā)這個調用.
前提：在類的設計上，每一個類都應當盡量降低成員的訪問權限邪蛔。
設計模式六大原則（6）：開閉原則
定義：一個軟件實體如類急黎、模塊和函數(shù)應該對擴展開放，對修改關閉侧到。
問題由來：在軟件的生命周期內(nèi)勃教，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時匠抗，可能會給舊代碼中引入錯誤故源，也可能會使我們不得不對整個功能進行重構，并且需要原有代碼經(jīng)過重新測試汞贸。
解決方案：當軟件需要變化時绳军，盡量通過擴展軟件實體的行為來實現(xiàn)變化印机，而不是通過修改已有的代碼來實現(xiàn)變化。
設計類時, 盡量讓這個類是足夠好,寫好了就不要去修改,如果新需求來,增加一些類就完事,原來的代碼能不動就不動.
設計人員需要猜測出最有可能發(fā)生的變化種類,然后構造抽象來隔離那些變化.
發(fā)生小的變化時门驾，就要及時去想辦法應對發(fā)生更大變化的可能射赛，重構修改同一處代碼時要一次搞定，同一個地方不要修改2次奶是。
開閉原則是面向對象設計中最基礎的設計原則楣责，它指導我們?nèi)绾谓⒎€(wěn)定靈活的系統(tǒng)。開閉原則可能是設計模式六項原則中定義最模糊的一個了诫隅，它只告訴我們對擴展開放腐魂，對修改關閉，可是到底如何才能做到對擴展開放逐纬，對修改關閉蛔屹，并沒有明確的告訴我們。以前豁生，如果有人告訴我“你進行設計的時候一定要遵守開閉原則”兔毒，我會覺的他什么都沒說，但貌似又什么都說了甸箱。因為開閉原則真的太虛了育叁。
在仔細思考以及仔細閱讀很多設計模式的文章后，終于對開閉原則有了一點認識芍殖。其實豪嗽，我們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則豌骏。也就是說龟梦，只要我們對前面5項原則遵守的好了，設計出的軟件自然是符合開閉原則的窃躲，這個開閉原則更像是前面五項原則遵守程度的“平均得分”计贰，前面5項原則遵守的好，平均分自然就高蒂窒，說明軟件設計開閉原則遵守的好躁倒；如果前面5項原則遵守的不好，則說明開閉原則遵守的不好洒琢。
其實筆者認為秧秉，開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現(xiàn)擴展細節(jié)纬凤。因為抽象靈活性好福贞，適應性廣，只要抽象的合理停士，可以基本保持軟件架構的穩(wěn)定挖帘。而軟件中易變的細節(jié)完丽，我們用從抽象派生的實現(xiàn)類來進行擴展，當軟件需要發(fā)生變化時拇舀，我們只需要根據(jù)需求重新派生一個實現(xiàn)類來擴展就可以了逻族。當然前提是我們的抽象要合理，要對需求的變更有前瞻性和預見性才行骄崩。
說到這里聘鳞，再回想一下前面說的5項原則，恰恰是告訴我們用抽象構建框架要拂，用實現(xiàn)擴展細節(jié)的注意事項而已：
單一職責原則告訴我們實現(xiàn)類要職責單一抠璃；
里氏替換原則告訴我們不要破壞繼承體系；
依賴倒置原則告訴我們要面向接口編程脱惰；
接口隔離原則告訴我們在設計接口的時候要精簡單一搏嗡；
迪米特法則告訴我們要降低耦合。
而開閉原則是總綱拉一，他告訴我們要對擴展開放采盒，對修改關閉。
最后說明一下如何去遵守這六個原則蔚润。對這六個原則的遵守并不是是和否的問題磅氨，而是多和少的問題，也就是說嫡纠，我們一般不會說有沒有遵守烦租，而是說遵守程度的多少。任何事都是過猶不及除盏，設計模式的六個設計原則也是一樣左权，制定這六個原則的目的并不是要我們刻板的遵守他們，而需要根據(jù)實際情況靈活運用痴颊。對他們的遵守程度只要在一個合理的范圍內(nèi)，就算是良好的設計屡贺。
談到設計模式,不得不推薦objc中國.很多很多優(yōu)秀的思想都是從objc中收獲而來.
