『設計模式』開發設計的七大原則,我做人還是挺有原則,那些代碼呢?

設計模式的七大原則:
  1. 單一職責原則SRP(Single Responsibility Principle)
    就一個類而言,應該僅有一個引起它變化的原因。
  2. 開放-關閉原則OCP(Open-CLosed Principle)
    一個軟件的實體應該對擴展開放,對修改關閉。
  3. 里氏代換原則(Liskov Substitution Principle)
    子類型必須能夠替換他們的基類(父類)。
  4. 依賴倒置原則DIP(Dependence Inversion Principle)
    要依賴於抽象,不要依賴於具體。
  5. 最少知識原則LKP(Least Knowledge Principle)或稱 迪米特法則(LoD)
    一個類對於其他類知道的越少越好,就是說一個對象應當對其他對象有儘可能少的瞭解,只和朋友通信,不和陌生人說話
  6. 接口隔離原則(ISP)
    使用多個專門的接口比使用單一的功能更多的總接口要好
  7. 合成/聚合原則
    要儘量使用合成/聚合,而不是繼承關係達到複用的目的
1.單一職責原則SRP(Single Responsibility Principle)

所謂單一職責原則就是一個類僅有一個引起它變化的原因。這裏變化的原因就是所說的“職責”。如果一個類有多個引起它變化的原因,那麼也就意味着這個類有多個職責,再進一步說,就是把多個職責耦合在一起了。

單一職責原則的核心就是控制類的粒度大小、將對象解禍、提高其內聚性,如果遵循單一職責原則將有以下優點:

  1. 降低類的複雜度。一個類只負責一項職責, 其邏輯肯定要比負責多項職責簡單得多。
  2. 提高類的可讀性。複雜性降低,自然其可讀性會提高。
  3. 提高系統的可維護性。可讀性提高,那自然更容易維護了。
  4. 變更引起的風險降低。變更是必然的,如果單一職責原則遵守得好, 當修改一個功能時,可以顯著降低對其他功能的影響。
2.開放-關閉原則OCP(Open-CLosed Principle)
  • 所謂開放-閉合原則,指的是,一個類應該對擴展開放,最修改關閉。一般也被簡稱開閉原則,開閉原則是設計中非常核心的一個原則。
  • 開閉原則要求的是,類的行爲是可以擴展的,而且是在不修改已有代碼的情況下進行擴展,也不必改動已有的源代碼或者二進制代碼。
  • 實現開閉原則的關鍵就在於合理地抽象、分離出變化和不變化的部分,爲變化的部分留下可擴展的方式,比如,鉤子方法或者是動態組合對象等。
  • 這個原則看起來也很簡單。但事實上,一個系統要全部做到遵守開閉原則,幾乎是不可能的,也沒這個必要。適度的抽象可以提高系統的靈活性,使其可擴展、可維護,但是過度的抽象,會大大的增加系統的複雜程度。應該在需要改變的地方應用開閉原則就可以了,而不用到處使用,從而陷入過度設計。

優點:

  1. 對軟件測試的影響
    軟件遵守開閉原則的話,軟件測試時只需要對擴展的代碼進行測試就可以了,因爲原有的測試
    代碼仍然能夠正常運行。
  2. 可以提高代碼的可複用性
    粒度越小,被複用的可能性就越大; 在面向對象的程序設計中,根據原子和抽象編程可以提高
    代碼的可複用性。
  3. 可以提高軟件的可維護性
    遵守開閉原則的軟件,其穩定性高和延續性強, 從而易於擴展和維護
3.里氏代換原則(Liskov Substitution Principle)

子類型(subtype)必須能夠替換它們的基(父)類型。(子類可以以父類的身份出現)。
比如,如果是父類是鳥,鳥會飛。企鵝🐧不會飛,企鵝是鳥嗎?所以企鵝不能繼承鳥這個類。

  1. 里氏替換原則是實現開閉原則的重要方式之一。
  2. 它克服了繼承中重寫父類造成的可複用性變差的缺點。
  3. 它是動作正確性的保證。即類的擴展不會給已有的系統引入新的錯誤, 降低了代碼出錯的可能性。
4.依賴倒置原則DIP(Dependence Inversion Principle)

所謂依賴倒置原則,指的是,要依賴於抽象,不要依賴於具體類。要做到依賴倒置,典型的應用應該做到:

  • 高層模塊不應該依賴於底層模塊,二者都應該依賴於抽象
  • 抽象不應該依賴於具體實現,具體實現應該依賴於抽象
  • 一般高層模塊包含對業務功能的處理和業務策略選擇,應該被重用的,是高層模塊去影響底層的具體實現。
  • 要針對接口編程,而不是針對實現編程

因此,這個底層的接口與應該由高層提出的,然後由底層實現的,也就是說底層接口的所有權在高層模塊,因此是一種所有權的倒置。

啓示:好的程序應該強內聚,松耦合。
優點:

  1. 依賴倒置原則可以降低類間的精合性。
  2. 依賴倒置原則可以提高系統的穩定性。
  3. 依賴倒置原則可以減少並行開發引起的風險。
  4. 依賴倒置原則可以提高代碼的可讀性和可維護性。
5.最少知識原則LKP(Least Knowledge Principle)或稱 迪米特法則(LoD)

這個原則用來指導我們在設計系統的時候,應該儘量減少對象之間的交互,對象只和自己的朋友談話,也就是隻和自己的朋友交互,從而鬆散類之間的耦合。通過鬆散類之間的耦合來降低類之間的相互依賴,這樣在修改系統的某一個部分的時候,就不會影響其他的部分,從而使得系統具有更好的維護性。

那麼哪些對象才能當做朋友呢?

  • 當前對象本身
  • 通過方法的參數傳遞過來的對象
  • 當前對象所創建的對象
  • 當前對象的實例變量所引用的對象
  • 方法內所創建或者實例化的對象

其根本思想:

  • 強調了類之間的松耦合。
  • 類之間的耦合越弱,越有利於複用,一個處於弱耦合的類被修改,不會對有關係的類造成波及。
  • 信息的隱藏促進了軟件的複用。

優點:

  • 降低了類之間的相合度, 提高了模塊的相對獨立性。
  • 由於相合度降低, 從而提高了類的可複用率和系統的擴展
6.接口隔離原則(ISP)

接口隔離原則(Interface Segregation Principle)講的是:使用多個專門的接口比使用單一的總接口要好。換而言之,從一個客戶類的角度來講:一個類對另外一個類的依賴性應當是建立在最小接口上的。

過於臃腫的接口是對接口的污染。不提倡使用,也不應該是用Dirt- Interface。
接口隔離原則是爲了約束接口、降低類對接口的依賴性,遵循接口隔離原則有以下優點:

  1. 將髒腫龐大的接口分解爲多個粒度小的接口,可以預防外來變更的擴散, 提高系統的靈活性和可維護性。
  2. 接口隔離提高了系統的內聚性,減少了對外交互,降低了系統的藕合性。
  3. 如果接口的粒度大小定義合理, 能夠保證系統的穩定性; 但是,如果定義過小,則會造成接口數量過多,使設計複雜化; 如果定義太大,靈活性降低,無法提供定製服務,給整體項目帶來無法預料的風險。
  4. 使用多個專門的接口還能夠體現對象的層次, 因爲可以通過接口的繼承, 實現對總接口的
    定義。
  5. 能減少項目工程中的代碼冗餘。過大的大接口裏面通常放置許多不用的方法,當實現這個接口的時候,被迫設計冗餘的代碼。
7.合成/聚合原則(Favor Composition Over Inheritance )

要儘量使用合成/聚合,而不是繼承關係達到複用的目的。

合成/聚合原則就是在一個新的對象裏面使用一些已有的對象,使之成爲新對象的一部分;新的對象通過向這些對象的委派達到複用已有。

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