1、引言來
設計模式表明了最佳的實踐,一般被有經驗的面向對象的軟件開發人員所採用。設計模式是軟件開發人員在軟件開發過程當中面臨的通常問題的解決方案。這些解決方案是衆多軟件開發人員通過至關長的一段時間的試驗和錯誤總結出來的。
設計模式主要是基於面向對象的如下原則:編程
2、設計模式分類
共分爲三大類設計模式
- 建立型模式,共五種:工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
- 結構型模式,共七種:適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
- 行爲型模式,共十一種:策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
除以上三大類之外還有兩類,即併發型模式和線程池模式。併發
3、設計模式六大原則
0.總原則-開閉原則
對擴展開放,對修改封閉。在程序須要進行拓展的時候,不能去修改原有的代碼,而是要擴展原有代碼,實現一個熱插拔的效果。即:爲了使程序的擴展性好,易於維護和升級。
1.單一職責原則(Single Responsibility Principle,簡稱SRP )
- 核心思想:應該有且僅有一個緣由引發類的變動
- 問題描述:假若有類Class1完成職責T1,T2,當職責T1或T2有變動須要修改時,有可能影響到該類的另一個職責正常工做。
- 好處:類的複雜度下降、可讀性提升、可維護性提升、擴展性提升、下降了變動引發的風險。
- 需注意:單一職責原則提出了一個編寫程序的標準,用「職責」或「變化緣由」來衡量接口或類設計得是否優良,可是「職責」和「變化緣由」都是不能夠度量的,因項目和環境而異。
2.里氏替換原則(Liskov Substitution Principle,簡稱LSP)
- 核心思想:在使用基類的的地方能夠任意使用其子類,能保證子類完美替換基類。
- 通俗來說:只要父類能出現的地方子類就能出現。反之,父類則未必能勝任。
- 好處:加強程序的健壯性,即便增長了子類,原有的子類還能夠繼續運行。
- 需注意:若是子類不能完整地實現父類的方法,或者父類的某些方法在子類中已經發生「畸變」,則建議斷開父子繼承關係 採用依賴、聚合、組合等關係代替繼承。
3.依賴倒置原則(Dependence Inversion Principle,簡稱DIP)
- 核心思想:高層模塊不該該依賴底層模塊,兩者都該依賴其抽象;抽象不該該依賴細節;細節應該依賴抽象;
- 說明:高層模塊就是調用端,低層模塊就是具體實現類。抽象就是指接口或抽象類。細節就是實現類。
- 通俗來說:依賴倒置原則的本質就是經過抽象(接口或抽象類)使個各種或模塊的實現彼此獨立,互不影響,實現模塊間的鬆耦合。
- 問題描述:類A直接依賴類B,假如要將類A改成依賴類C,則必須經過修改類A的代碼來達成。這種場景下,類A通常是高層模塊,負責複雜的業務邏輯;類B和類C是低層模塊,負責基本的原子操做;假如修改類A,會給程序帶來沒必要要的風險。
- 解決方案:將類A修改成依賴接口interface,類B和類C各自實現接口interface,類A經過接口interface間接與類B或者類C發生聯繫,則會大大下降修改類A的概率。
- 好處:依賴倒置的好處在小型項目中很難體現出來。但在大中型項目中能夠減小需求變化引發的工做量。使並行開發更友好。
4.接口隔離原則(Interface Segregation Principle,簡稱ISP)
- 核心思想:類間的依賴關係應該創建在最小的接口上
- 通俗來說:創建單一接口,不要創建龐大臃腫的接口,儘可能細化接口,接口中的方法儘可能少。也就是說,咱們要爲各個類創建專用的接口,而不要試圖去創建一個很龐大的接口供全部依賴它的類去調用。
- 問題描述:類A經過接口interface依賴類B,類C經過接口interface依賴類D,若是接口interface對於類A和類B來講不是最小接口,則類B和類D必須去實現他們不須要的方法。
- 需注意:
- 接口儘可能小,可是要有限度。對接口進行細化能夠提升程序設計靈活性,可是若是太小,則會形成接口數量過多,使設計複雜化。因此必定要適度
- 提升內聚,減小對外交互。使接口用最少的方法去完成最多的事情
- 爲依賴接口的類定製服務。只暴露給調用的類它須要的方法,它不須要的方法則隱藏起來。只有專一地爲一個模塊提供定製服務,才能創建最小的依賴關係。
5.迪米特法則(Law of Demeter,簡稱LoD)
- 核心思想:類間解耦。
- 通俗來說: 一個類對本身依賴的類知道的越少越好。自從咱們接觸編程開始,就知道了軟件編程的總的原則:低耦合,高內聚。不管是面向過程編程仍是面向對象編程,只有使各個模塊之間的耦合儘可能的低,才能提升代碼的複用率。低耦合的優勢不言而喻,可是怎麼樣編程才能作到低耦合呢?那正是迪米特法則要去完成的。
6.開放封閉原則(Open Close Principle,簡稱OCP)
- 核心思想:儘可能經過擴展軟件實體來解決需求變化,而不是經過修改已有的代碼來完成變化
- 通俗來說: 一個軟件產品在生命週期內,都會發生變化,既然變化是一個既定的事實,咱們就應該在設計的時候儘可能適應這些變化,以提升項目的穩定性和靈活性。
4、總結來
- 單一職責原則,實現類要職責單一。
- 里氏替換原則,不要破壞繼承體系。
- 依賴倒置原則,要面向接口編程。
- 接口隔離原則,在設計接口的時候要精簡單一。
- 迪米特法則,要下降耦合。
- 開閉原則是總綱,對擴展開放,對修改關閉。