設(shè)計模式在編程中有重要的指導(dǎo)意義，每個項目在架構(gòu)階段就應(yīng)該很好的滿足設(shè)計模式的六大原則，當(dāng)然也要根據(jù)項目的實際情況來權(quán)衡取舍，平衡效率跟質(zhì)量的關(guān)系。下面簡單介紹下設(shè)計模式的六大原則。

1.單一職責(zé)原則

a）Single Responsibility Principle，簡稱SRP。這個原則是存在爭議的，就是每個類的設(shè)計到底是“單一職責(zé)”還是盡可能的承擔(dān)更多的“職責(zé)”？這個問題我覺得應(yīng)該就項目的實際情況來決定，比如項目規(guī)模比較大，就應(yīng)該把“職責(zé)”拆分的更細(xì)，這樣可擴展性就會增加，同樣的工作量會增加，在使用上可能需要的條件更多。簡單的舉個例子就：類的屬性跟行為，如果分開，完成一件事情就要屬性跟行為的不同接口結(jié)合到一起來實現(xiàn)，但是每個類的功能會很清晰。單一職責(zé)原則要求一個類只有一個原因引起是改變，我個人認(rèn)為關(guān)于這個“尺度”其實可以根據(jù)實際情況來操作，可以是多于一個原因。

b）單一職責(zé)的好處有哪些呢？我們可以總結(jié)一下，不防結(jié)合上面“屬性跟行為”的例子：

*類的復(fù)雜性降低了，實現(xiàn)什么職責(zé)都有清晰明確的定義（我只負(fù)責(zé)一件事）。

*可讀性提高，這個是復(fù)雜性降低的必然結(jié)果。

*可維護性提高。

*變更引起的風(fēng)險降低了，程序的變更是必不可少的，變更一個功能只需要修改一個接口就可，對其他的沒有影響，對系統(tǒng)的穩(wěn)定性、可擴展性、維護性都很大的幫助。

2.里氏代換原則

a）在面向?qū)ο蟮木幊陶Z言中，繼承是必不可少的、非常優(yōu)秀的語言機制。

優(yōu)點是：

*代碼共享，減少創(chuàng)建類的工作量，每個子類都擁有父類的方法用途屬性。

*提高代碼的重用性。

*子類形似父類又異于父類。

*提高代碼的可擴展性，通過繼承父類來擴展父類的功能。

*提高產(chǎn)品或者項目的開放性。

缺點：

*繼承是侵入性的，只要是繼承就必須擁有父類的所有屬性與方法。

*降低代碼的靈活性。

*增強了耦合性。

因為繼承的這些有確定，下面我們引出解決方案：里氏代換原則，Liskov Substitution Principle。里氏代換原則為繼承定義了一個規(guī)范，包含四層含義：

*子類必須完全實現(xiàn)父類的方法。

*子類可以有自己的個性。

*覆蓋或者實現(xiàn)父類的方法時輸入?yún)?shù)可以被放大。

*覆蓋或者實現(xiàn)父類的方法時輸出結(jié)果可以被縮小。

b）里氏代換原則的目的就是增強程序的健壯性，及時版本升級也可以保持良好的兼容性。

3.依賴倒置原則：

a）Dependence Inversion Principle。其原始定義包含三層含義：

*高層模塊不應(yīng)該一覽底層模塊，兩者都應(yīng)該依賴其抽象。

*抽象的不應(yīng)該依賴細(xì)節(jié)。

*細(xì)節(jié)不應(yīng)該依賴抽象。

具體在Java語言中的表現(xiàn)：

*模塊間的依賴通過抽象發(fā)生，實現(xiàn)類之間不直接發(fā)生依賴關(guān)系，依賴通過接口或者抽象類來實現(xiàn)。

*接口或者抽象類不依賴實現(xiàn)類。

*實現(xiàn)類依賴接口或抽象類。

其實更加簡潔的定義就是面向接口編程OOD（Object-Oriented

Design）的精髓之一。

4.接口隔離原則

a）接口隔離原則的定義：客戶端不應(yīng)該依賴其不需要的接口，類間的依賴關(guān)系應(yīng)該建立在最小的接口上。簡單理解就是，客戶端應(yīng)該以來其需要的接口，不需要的接口要剔除掉，也就是你依賴的接口的方法對于客戶端來說應(yīng)該是都有用的；最小的接口也就是要求接口細(xì)化，接口純潔。b）接口隔離原則對接口進了規(guī)范約束：

*接口要盡量小，對于“小”也是有“尺度”的，需要自己把握。

*接口要高內(nèi)聚，提高接口、類、模塊的處理能力，減少對外的交互。

*定制服務(wù)，一個系統(tǒng)或者系統(tǒng)內(nèi)的模塊必然會有耦合，既然耦合，就要有相互訪問的接口，所以設(shè)計時就需要為每個參與者定制服務(wù)。

*接口設(shè)計是有限度的，這個就是權(quán)衡接口的規(guī)模跟結(jié)構(gòu)復(fù)雜度的關(guān)系，保證靈活性、開發(fā)難度、可維護性在接受的范圍內(nèi)。

5.迪米特法則

a）Law of Demeter，也稱為最小知識原則（Least

Knowledge Principle）：一個對象應(yīng)該對其他對象有最少的只是了解。通俗的講，一個類應(yīng)該對自己需要耦合或者調(diào)用的類知道的最少。

b）迪米特法則對低耦合提出了明確的要求：

*只跟朋友交流，如果學(xué)過UML的話，應(yīng)該知道，對象之間的耦合，存在組合、聚合、依賴等關(guān)系。

*朋友之間也有距離，具體的講，一個類的public屬性或方法越多，修改時涉及的問題就越多，變更引起的風(fēng)險擴散也就越大。要將public的屬性或者方法降到最低。

*是自己的就是自己的，如果一個方法在本類中接不增加類間關(guān)系，也對本類不產(chǎn)生負(fù)面影響，那就可以放置在本類中。

*謹(jǐn)慎使用Serializable，這個問題實際中出現(xiàn)很少，就是客戶端與服務(wù)端通信是屬性權(quán)限影響序列化的問題。

6.開閉原則

a）開閉原則是Java世界里最基礎(chǔ)的設(shè)計原則，這指導(dǎo)我們?nèi)绾谓⒁粋€穩(wěn)定、靈活的系統(tǒng)。開閉原則的核心定：對擴展開放，對修改關(guān)閉。

b）開閉原則的重要性

*開閉原則對測試的影響，有變化時，原有健壯代碼不修改，通過擴展實現(xiàn)變化，這樣已經(jīng)測試過的部分就不要再測試。

*開閉原則可以提高復(fù)用性

*開閉原則可以提高可維護性

*面向?qū)ο蟮囊蟆?/p>

c）開閉原則的實際使用：

*抽象約束，通過接口或抽象類約束一組可能變化的行為并能實現(xiàn)對擴展開放。

*元數(shù)據(jù)控制模塊行為，元數(shù)據(jù)，metadata，也就是配置參數(shù)，這樣可以減少重復(fù)開發(fā)，也就是很多參數(shù)可以是服務(wù)端提供的。

*定制項目章程，對于項目而言，約定由于配置。

*封裝變化，將相同的變化封裝到一個接口或者是抽象類中；將不同的變化封裝到不同的接口或抽象類中。

PS：如有謬誤歡迎指正！