面向對象設計的6個設計原則,23個經典設計模式

設計原則

1.單一職責原則java

定義:不要存在多於一個致使類變動的緣由。通俗的說,即一個類只負責一項職責。編程

問題由來:類T負責兩個不一樣的職責:職責P1,職責P2。當因爲職責P1需求發生改變而須要修改類T時,有可能會致使本來運行正常的職責P2功能發生故障。設計模式

解決方案:遵循單一職責原則。分別創建兩個類T一、T2,使T1完成職責P1功能,T2完成職責P2功能。這樣,當修改類T1時,不會使職責P2發生故障風險;同理,當修改T2時,也不會使職責P1發生故障風險。架構

2.里氏替換原則函數

定義1:若是對每個類型爲 T1的對象 o1,都有類型爲 T2 的對象o2,使得以 T1定義的全部程序 P 在全部的對象 o1 都代換成 o2 時,程序 P 的行爲沒有發生變化,那麼類型 T2 是類型 T1 的子類型。測試

定義2:全部引用基類的地方必須能透明地使用其子類的對象。ui

問題由來:有一功能P1,由類A完成。現須要將功能P1進行擴展,擴展後的功能爲P,其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成,則子類B在完成新功能P2的同時,有可能會致使原有功能P1發生故障。spa

解決方案:當使用繼承時,遵循里氏替換原則。類B繼承類A時,除添加新的方法完成新增功能P2外,儘可能不要重寫父類A的方法,也儘可能不要重載父類A的方法prototype

只要父類能出現的地方,其子類就應該能出現。也就是用子類替換父類後,保證程序照樣運行。設計

里氏替換原則通俗的來說就是:子類能夠擴展父類的功能,但不能改變父類原有的功能,不然可能致使原來的功能出錯。

3.依賴倒置原則

依賴倒置原則基於這樣一個事實:相對於細節的多變性,抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構要穩定的多。在 java中,抽象指的是接口或者抽象類,細節就是具體的實現類,使用接口或者抽象類的目的是制定好規範和契約,而不去涉及任何具體的操做,把展示細節的任 務交給他們的實現類去完成。         

依賴倒置原則的核心思想是面向接口編程

4.接口隔離原則

定義:客戶端不該該依賴它不須要的接口;一個類對另外一個類的依賴應該創建在最小的接口上。

問題由來:類A經過接口I依賴類B,類C經過接口I依賴類D,若是接口I對於類A和類B來講不是最小接口,則類B和類D必須去實現他們不須要的方法。

解決方案:將臃腫的接口I拆分爲獨立的幾個接口,類A和類C分別與他們須要的接口創建依賴關係。也就是採用接口隔離原則

接口細化,也就是接口中的方法要儘可能少。

5.迪米特法則

定義:一個對象應該對其餘對象保持最少的瞭解。

問題由來:類與類之間的關係越密切,耦合度越大,當一個類發生改變時,對另外一個類的影響也越大。

解決方案:儘可能下降類與類之間的耦合。

也稱爲最少知識原則,其定義爲:一個對象應當對其餘對象有最少的瞭解。也就是一個類中不要有過多的其餘類。

6.開閉原則

定義:一個軟件實體如類、模塊和函數應該對擴展開放,對修改關閉。

問題由來:在軟件的生命週期內,由於變化、升級和維護等緣由須要對軟件原有代碼進行修改時,可能會給舊代碼中引入錯誤,也可能會使咱們不得不對整個功能進行重構,而且須要原有代碼通過從新測試。

解決方案:當軟件須要變化時,儘可能經過擴展軟件實體的行爲來實現變化,而不是經過修改已有的代碼來實現變化。

一個軟件實體(如類,模塊,和函數)應該對擴展開放,對修改關閉。

設計模式

1、建立型模式
1. 抽象工廠(abstract factory) 
2. 生成器(builder)
3. 工廠方法(factory method)
4. 原型(prototype)
5. 單件(singleton)
2、結構型模式
1. 適配器(adapter)
2. 橋接(bridge)
3. 組成(composite)
4. 裝飾(decorator)
5. 外觀(facade)
6. 享元(flyweight)
7. 代理(proxy)
3、行爲模式 1. 職責鏈(chain of responsibility) 2. 命令(command) 3. 解釋器(interpreter) 4. 迭代器(iterator) 5. 中介者(mediator) 6. 備忘錄(memento) 7. 觀察者(observer) 8. 狀態(state) 9. 策略(strategy) 10. 模版方法(template method) 11. 訪問者(visitor)

相關文章
相關標籤/搜索