設計模式六大原則

1.開閉原則。

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

解讀:用抽象構建框架,用實現擴展細節。不以改動原有類的方式來實現新需求,而是應該以實現事先抽象出來的接口(或具體類繼承抽象類)的方式來實現。

優點:開閉原則的優點在於可以在不改動原有代碼的前提下給程序擴展功能。增加了程序的可擴展性,同時也降低了程序的維護成本。

2.單一職責原則。

一個類只允許有一個職責,即只有一個導致該類變更的原因。

解讀:類職責的變化往往就是導致類變化的原因:也就是說如果一個類具有多種職責,就會有多種導致這個類變化的原因,從而導致這個類的維護變得困難。往往在軟件開發中,隨着需求的不斷增加,可能會給原來的類添加一些本來不屬於它的一些職責,從而違反了單一職責原則。如果我們發現當前類的職責不僅僅有一個,就應該將本來不屬於該類真正的職責分離出去。不僅僅是類,函數也要遵循單一職責原則,即一個函數製作一件事情。如果發現一個函數裏面有不同的任務,則需要將不同的任務以另一個函數的形式分離出去。

優點:如果類與方法的職責劃分的很清晰,不但可以提高代碼的可讀性,更實際性地更降低了程序出錯的風險,因爲清晰的代碼會讓bug無處藏身,也有利於bug的追蹤,也就是降低了程序的維護成本。

3.依賴倒置原則。

依賴抽象而不是依賴實現。抽象不應該依賴細節,細節應該依賴抽象。高層模塊不能依賴低層模塊,二者都應該依賴抽象。

解讀:針對接口編程,而不是針對實現編程。儘量不要從具體的類派生,而是以繼承抽象類或實現接口來實現。關於高層模塊與低層模塊的劃分可以按照決策能力的高低進行劃分。業務層自然就處於上層模塊,邏輯層和數據層自然就歸類爲底層。

優點:通過抽象來搭建框架,建立類和類的關聯,以減少類間的耦合性。而且以抽象搭建的系統要比以具體實現搭建的系統更加穩定,擴展性更高,同時也便於維護。

4.接口分離原則。

多個特定的客戶端接口要好於一個通用性的總接口。

解讀:客戶端不應該依賴它不需要實現的接口。不建立龐大臃腫的接口,應儘量細化接口,接口中的方法應儘量少。需要注意的是接口的力度也不能太小,如果過小,則會造成接口數量過多,使設計複雜化。

優點:避免同一個接口裏麪包含不同類職責的方法,接口責任劃分更加明確,符合高內聚低耦合的思想。

5.迪米特法則

一個對象應該對儘可能少的對象有接觸,也就是隻接觸那些真正需要接觸的對象。

解讀:迪米特法則也叫做最少知道原則,一個類應該只和它的成員變量,方法的輸入,返回參數中的類作交流,而不應該引入其他的類(間接交流)。

優點:實踐迪米特法則可以良好地降低類與類之間的耦合,減少類與類之間的關聯程度,讓類與類之間的協作更加直接。

6.里氏替換原則。

所有引用基類的地方必須能透明地使用其子類的對象,也就是說子類對象可以替換其父類對象,而程序執行效果不變。

解讀:在繼承體系中,子類中可以增加自己特有的方法,也可以實現父類的抽象方法,但是不能重寫父類的非抽象方法,否則該繼承關係就不是一個正確的繼承關係。

優點:可以檢驗繼承使用的正確性,約束繼承在使用上的泛濫。

發佈了195 篇原創文章 · 獲贊 41 · 訪問量 12萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章