設(shè)計模式原則，其實就是程序員在編程時，應當遵守的原則，也是各種設(shè)計模式的基礎(chǔ)，即設(shè)計模式為什么這樣設(shè)計的依據(jù)。
1）單一職責原則
定義：一個類，只有一個引起它變化的原因。即：應該只有一個職責。
如果一個類有一個以上的職責，這些職責就耦合在了一起，就會出現(xiàn)當一個職責發(fā)生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用性。例如：要實現(xiàn)邏輯和界面的分離。需要說明的一點是單一職責原則不只是面向?qū)ο缶幊趟枷胨赜械模灰悄K化的程序設(shè)計，都需要遵循這一重要原則。
問題由來：類T負責兩個不同的職責：職責P1，職責P2。當由于職責P1需求發(fā)生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發(fā)生故障。
解決方法：分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發(fā)生故障風險；同理，當修改T2時，也不會使職責P1發(fā)生故障風險。
思考：單一職責是什么？是只負責一種責任嗎？類比到類的話，是只實現(xiàn)一種功能嗎？百度了一下職責的定義：“所負責的范圍和承擔的一系列工作任務，以及完成這些工作任務所需承擔的相應責任”，哦哦，那我可以理解成老師有育人的職責，然后育人又可以分為一系列任務~~授課、解惑等，然后作為一個老師，不能有食堂阿姨的職責，如果有的話，就會造成關(guān)系復雜化，如果食堂提早飯點時間，那么就有可能會對老師的正常上課的時間造成影響，所以就要有兩種身份，老師和食堂阿姨，分別負責自己的職責，互不干擾。這只是我自己的思考，是否正確我也不清楚，哈哈。
2）接口隔離原則
定義：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
問題由來：如果接口有五個方法，分別為m1、m2、m3、m4、m5，類A通過接口I依賴于類B的m1和m2方法，類C通過接口I依賴于類D的m3、m4和m5方法，接口I對于類A和類C來說不是最小接口，因為類B和類D要去實現(xiàn)他們根本不需要的方法 。
解決方法：1、 使用委托分離接口。2、 使用多重繼承分離接口。3、將臃腫的接口I拆分為獨立的兩個接口，類A和類C分別與他們需要的接口建立依賴關(guān)系。也就是采用接口隔離原則。
思考:這個原則還挺好理解的，只要自己想要的，其它多余的我一概不要，恩，沒毛病，做人不能太貪心。
3）依賴倒轉(zhuǎn)(倒置)原則
定義：高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節(jié)；細節(jié)應該依賴抽象。中心思想是面向接口編程 。
問題由來：類A直接依賴類B，假如要將類A改為補在依賴類B,改為依賴C，則必須通過修改類A的代碼來實現(xiàn)。這種場景下，類A一般是高層模塊，負責復雜的業(yè)務邏輯；類B和類C是低層模塊，負責基本的原子操作；修改類A，可能會給程序帶來不必要的風險。
解決方法：將類A修改為依賴接口I，類B和類C各自實現(xiàn)接口I，類A通過接口I間接與類B或者類C發(fā)生聯(lián)系，則會大大降低修改類A的幾率。
思考：這個原則讓我想起了，List list = new ArrayList();和ArrayList list = new ArrayList()；的區(qū)別，方法實現(xiàn)依賴于抽象，不依賴于具體的實現(xiàn)類，假如后期要把依賴改成LinkedList的話，直接把new ArrayList()改成new LinkedList()就可以了，如果直接依賴于實現(xiàn)類的話，因為它們中具體的方法有些區(qū)別，一修改的話，就需要改動程序。
4）里氏替換原則
定義：任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)，也就是子類必須能夠替換掉它們的父類。
問題由來：有一功能P1，由類A完成?，F(xiàn)需要將功能P1進行擴展，擴展后的功能為P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導致原有功能P1發(fā)生故障。
解決方法：類B繼承類A時，除添加新的方法完成新增功能P2外，盡量不要重寫父類A的方法，也盡量不要重載父類A的方法
思考：這原則怎么感覺怪難理解的？可以這樣理解嘛，假如有鳥這個父類，然后它有這個會飛方法，然后它的子類貓頭鷹、麻雀都繼承了這個方法，都會飛，但是有個特例，企鵝，企鵝是鳥，它不會飛，它要重寫父類的會飛方法，如果是這樣子的話，當外部程序要調(diào)用父類的時候，都得判斷一下是不是企鵝，不然程序會有bug，這樣子的話就不滿足里氏替換原則，同時也不滿足開閉原則，因為需要修改外部程序進行判斷。
5）開閉原則
定義：軟件實體應當對擴展開放，對修改關(guān)閉。這句話說得有點專業(yè)，更通俗一點講，也就是：軟件系統(tǒng)中包含的各種組件，例如類以及功能等，應該在不修改現(xiàn)有代碼的基礎(chǔ)上，去擴展新功能。開閉原則中原有“開”，是指對于組件功能的擴展是開放的，是允許對其進行功能擴展的；開閉原則中“閉”，是指對于代碼的修改是封閉的，即不應該修改原有的代碼。
問題由來：在軟件的生命周期內(nèi)，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構(gòu)，并且需要原有代碼經(jīng)過重新測試。這就對我們的整個系統(tǒng)的影響特別大，這也充分展現(xiàn)出了系統(tǒng)的耦合性如果太高，會大大的增加后期的擴展，維護。為了解決這個問題，偉人們總結(jié)出了開閉原則。解決開閉原則的根本其實還是在解耦合。所以，我們面向?qū)ο蟮拈_發(fā)，我們最根本的任務就是解耦合。
解決方法：當軟件需要變化時，盡量通過擴展軟件實體的行為來實現(xiàn)變化，而不是通過修改已有的代碼來實現(xiàn)變化。
思考：這個就讓我想起了“牽一發(fā)而動全身”這個詞語，可能你對源代碼的一點改動，就有可能造成程序的炸裂，估計程序員們都深有體會。
6）迪米特法則（最少知道原則）
定義：迪米特法則又叫最少知道原則，即：一個對象應該對其他對象保持最少的了解。如果兩個類不必彼此直接通信，那么這兩個類就不應當發(fā)生直接的相互作用。如果其中一個類需要調(diào)用另一個類的某一個方法的話，可以通過第三者轉(zhuǎn)發(fā)這個調(diào)用。簡單定義為只與直接的朋友通信。首先來解釋一下什么是直接的朋友：每個對象都會與其他對象有耦合關(guān)系，只要兩個對象之間有耦合關(guān)系，我們就說這兩個對象之間是朋友關(guān)系。耦合的方式很多，依賴、關(guān)聯(lián)、組合、聚合等。其中，我們稱出現(xiàn)成員變量、方法參數(shù)、方法返回值中的類為直接的朋友，而出現(xiàn)在局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要作為局部變量的形式出現(xiàn)在類的內(nèi)部。
問題由來：類與類之間的關(guān)系越密切，耦合度越大，當一個類發(fā)生改變時，對另一個類的影響也越大。
解決方法：盡量降低類與類之間的耦合。 自從我們接觸編程開始，就知道了軟件編程的總的原則：低耦合，高內(nèi)聚。無論是面向過程編程還是面向?qū)ο缶幊?，只有使各個模塊之間的耦合盡量的低，才能提高代碼的復用率。
思考：不知道可不可以理解成類似于面向?qū)ο缶幊痰姆庋b性。封裝是指隱藏對象的屬性和實現(xiàn)細節(jié)，僅對外提供公共訪問方式，好吧這個原則有點難理解。
7）合成復用（合成/聚合）原則
定義：也有人叫做合成/聚合原則，及盡量使用合成/聚合，盡量不要使用類繼承。換句話說，就是能用合成/聚合的地方，絕不用繼承。
問題由來：對象的繼承關(guān)系在編譯時就定義好了，所以無法在運行時改變從父類繼承的子類的實現(xiàn)；子類的實現(xiàn)和它的父類有非常緊密的依賴關(guān)系，以至于父類實現(xiàn)中的任何變化必然會導致子類發(fā)生變化；當你復用子類的時候，如果繼承下來的實現(xiàn)不適合解決新的問題，則父類必須重寫或者被其它更適合的類所替換，這種依賴關(guān)系限制了靈活性，并最終限制了復用性。
思考：好像我寫代碼挺少用到繼承的，看來這個原則與我有緣。
