一、設計模式常用的七大原則

單一職責原則：一個類應該只負責一項職責

接口隔離原則：客戶端不應該依賴它不需要的接口，即一個類對另一個類的依賴應該建立在最小的接口上

依賴倒轉原則

里氏替換原則

開閉原則

迪米特法則

合成復用原則

二、單一職責原則

1. 單一職責原則注意事項和細節(jié) 降低類的復雜度，一個類只負責一項職責

2.提高類的可讀性，可維護性

3.降低變更引起的風險

4.通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在代碼級違反單一職責原則；只有類中方法數(shù)量足夠少，可以在方法級別保持單一職責原則

三、接口隔離原則

接口隔離原則注意事項和細節(jié)

segregation_origin

segregation_improve

四、依賴倒轉原則

依賴倒轉原則思想

1.高層模塊不應該依賴底層模塊，二者都應該依賴其抽象

2.抽象不應該依賴細節(jié)，細節(jié)應該依賴抽象

3.依賴倒轉的中心思想是面向接口編程

4.依賴倒轉原則是基于這樣的設計理念：相對于細節(jié)的多邊性，抽象的東西要穩(wěn)定的多。以抽象為基礎搭建的架構比以細節(jié)為基礎的架構要穩(wěn)定的多。在java中，抽象指的是接口或抽象類，細節(jié)就是具體的實現(xiàn)類

5.使用接口或抽象類的目的是指定好規(guī)范，而不涉及任何具體的操作，把展示細節(jié)的任務交給他們的實現(xiàn)類去完成

依賴關系傳遞的三種方式和應用案例

1.接口傳遞

2.構造方法傳遞

3.setter方法傳遞

依賴倒轉原則注意事項和細節(jié)

1.低層模塊盡量都要有抽象類或接口，或者兩者都有，程序穩(wěn)定性更好

2.變量的聲明類型盡量是抽象類或接口，這樣我們的變量引用和實際對象間，就存在一個緩沖層，利于程序拓展和優(yōu)化

3.繼承時遵循里氏替換原則

五、里氏替換原則

 OO中的繼承性的思考和說明

1.繼承包含這樣一層含義：父類中凡是已經(jīng)實現(xiàn)好的方法，實際上是在設定規(guī)范和契約，雖然它不強制要求所有的子類必須遵循這些契約，但是如果子類對這些已經(jīng)實現(xiàn)的方法任意修改，就會對整個繼承體系造成破壞

2.繼承在給程序設計帶來便利的同時，也帶來了弊端。比如使用繼承會給程序帶來侵入性，程序的可移植性降低，增加對象間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，并且父類修改后，所涉及到子類的功能可能產(chǎn)生故障

里氏替換原則思想

1.如果對每個類型為T1的對象o1，都有類型為T2的對象o2，使得以T1定義的所有程序P在所有的對象o1都替換成o2時，程序P的行為沒有發(fā)生變化，那么類型T2是類型T1的子類型。換句話說，所有引用基類的地方必須能透明地使用其子類的對象

2.在使用繼承時，遵循里氏替換原則，在子類中盡量不要重寫父類的方法

3.里氏替換原則告訴我們，繼承實際上讓兩個類耦合性增強了，在適當?shù)那闆r下，可以通過聚合，組合，依賴來解決問題

liskov_origin

liskov_improve依賴

liskov_improve聚合

liskov_improve組合

六、開閉原則

基本介紹

1.一個軟件實體如類，模塊和函數(shù)應該對擴展開放（對提供方），對修改關閉（對使用方）。用抽象構建框架，是實現(xiàn)擴展細節(jié)

2.當軟件需要變化時，盡量通過擴展軟件實體的行為為實現(xiàn)變化，而不是通過修改已有的代碼來實現(xiàn)變化

七、迪米特法則

基本介紹

1.一個對象應該對其他對象保持最少的了解

2.類與類關系越密切，耦合度越大

3.迪米特法則又叫最少知道原則，即一個類對自己依賴的類知道越少越好。也就是說，對于被依賴的類不管多么復雜，都盡量將邏輯封裝在類的內(nèi)部。對外除了提供的public方法，不對外泄露任何信息

八、合成復用原則

基本介紹

原則是盡量使用合成/聚合的方式，而不是使用繼承

到此這篇關于Java設計模式常用的七大原則總結的文章就介紹到這了,更多相關Java設計模式七大原則內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論