大話設計模式筆記(三)の六大原則

單一職責原則

英文:Single Responsibility Principle,簡稱SRP

定義

就一個類而言,應該僅有一個引起它變化的原因。

描述

  • 如果一個類承擔的職責過多,就等於把這些職責耦合在一起,一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,當變化發生時,設計會遭受到意想不到的破壞。
  • 軟件設計真正要做的許多內容,就是發現職責並把那些職責相互分離。
  • 如果能想到多於一個動機去改變一個類,那麼這個類就具有多於一個的職責。

開放-封閉原則

英文:Open Closed Principle,簡稱OCP

定義

是說軟件實體(類、模塊、函數等)應該可以擴展,但是不可修改。

描述

  • 也就是對擴展是開放的,對更改是封閉的
  • 無論模塊是多麼的“封閉”,都會存在一些無法對之封閉的變化。既然不可能完全封閉,設計人員必須對於他設計的模塊應該對哪些變化封閉做出選擇。他必須把先猜測出最有可能發生的變化種類,然後構造抽象來隔離那些變化
  • 在我們最初編寫代碼時,假設變化不會發生。當變化發生時,我們就創建抽象來隔離以後發生的同類變化。
  • 面對需求,對程序的改動時通過增加新代碼進行的,而不是更改現有的代碼。
  • 我們希望的是開發工作展開不久就知道可能發生的變化。查明可能發生的變化所等待的時間越長,要創建正確的抽象就越困難。
  • 開放-封閉原則是面向對象設計的核心所在。遵循這個原則可以帶來面向對象技術,所聲稱的巨大好處,也就是可維護、可擴展、可複用、靈活性好。開發人員應該僅對程序中呈現出頻繁變化的那些部分作出抽象,然而,對應用程序中每個部分都刻意的進行抽象不是一個好主意。拒絕不成熟的抽象和抽象本身一樣重要

依賴倒轉原則

英文:Dependence Inversion Principle,簡稱DIP

定義

高層模塊不應該依賴低層模塊,兩個都應該依賴抽象;抽象不應該依賴細節,細節應該依賴抽象。

描述

  • 說白了就是,針對接口編程,不要對實現編程
  • 依賴倒轉其實可以說是面向對象設計的標誌,用哪種語言來編寫程序不重要,如果編寫時考慮的是如果針對抽象編程而不是針對細節編程,即程序中所有的依賴關係都是終止於抽象類或者接口,那就是對象的設計,反之那就是過程化的設計了。

里氏代換原則

英文:Liskov Substitution Principle,簡稱LSP

定義

子類型必須能夠替換掉它們的父類型。

描述

  • 一個軟件實體如果使用的是一個父類的話,那麼一定適用於其子類,而且它察覺不出父類對象和子類對象的區別。也就是說,在軟件裏面,把父類都替換成它的子類,程序行爲沒有變化
  • 只有當子類可以替換掉父類,軟件單位的功能不受影響時,父類才能真正被複用,而子類也能夠在父類的基礎上增加新的行爲。
  • 由於子類型的可替換性才使得使用父類類型的模塊在無需修改的情況下就可以擴展。

迪米特法則

英文:Law of Demeter,簡稱LoD

定義

也叫最少知識原則。如果兩個類不必彼此直接通信,那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話,可以通過第三者轉發這個調用。

描述

  • 迪米特法則的根本思想是強調了類之間的松耦合
  • 類之間的耦合越弱,越有利於複用,一個處在弱耦合的類被修改,不會對有關係的類造成波及。

接口隔離原則

雖然該原則在《大話設計模式》沒有明確指出,但實際上隱含在了其他模式或原則中。

英文:Interface Segregation Principle,簡稱ISP

定義

一個類對另外一個類的依賴性應當建立在最小的接口上。客戶端程序不應該依賴它不需要的接口方法。

描述

  • 接口隔離原則單一職責原則在概念上有一定的交叉。兩者都是爲了提高類的內聚性,降低它們之間的耦合性,體現了封裝的思想。但兩者是不同的。
  • 接口隔離原則強調的是接口對客戶端的承諾越少越好,並且做到專一。當某個客戶端程序的要求發生變化時迫使接口發生變化,影響到客戶端程序的可能性越小越好。
  • 接口隔離原則注重的是對接口依賴的隔離,用於約束接口,主要針對抽象和整體框架的構建
  • 單一職責原則注重的是職責,用於約束類,主要針對程序中實現和細節

總結

實際上很多設計模式在概念上也有一定的交叉,如果只是根據一段代碼來判斷屬於哪種設計模式,也是很難區分的,甚至還包含多種的混合。因此不要一直糾結於其中的思想到底屬於哪一種,理解其中的含義並能應用至實際開發當中纔是最重要的

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章