設計模式中的六大原則

單一職責原則

定義：不要存在多于一個導緻類變更的原因。通俗的說，即一個類隻負責一項職責。

裡氏替換原則

定義1：如果對每一個類型為 T1 的對象 o1，都有類型為 T2 的對象o2，使得以 T1 定義的所有程式 P 在所有的對象 o1

都代換成 o2 時，程式 P 的行為沒有發生變化，那麼類型 T2 是類型 T1 的子類型。

定義2：所有引用基類的地方必須能透明地使用其子類的對象。也就是說任何基類可以出現的地方，子類一定可以出

現。

裡氏替換原則通俗的來講就是：子類可以擴充父類的功能，但不能改變父類原有的功能。它包含以下4層含義：

1). 子類可以實作父類的抽象方法，但不能覆寫父類的非抽象方法。

2). 子類中可以增加自己特有的方法。

3). 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松。

4). 當子類的方法實作父類的抽象方法時，方法的後置條件（即方法的傳回值）要比父類更嚴格。

依賴倒置原則

定義：高層子產品不應該依賴低層子產品，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。

依賴倒置原則的核心思想是：面向接口程式設計。

傳遞依賴關系有三種方式：1.接口傳遞，2.構造方法傳遞，3.setter方法傳遞。

在實際程式設計中，我們一般需要做到如下3點：

1). 低層子產品盡量都要有抽象類或接口，或者兩者都有。

2). 變量的聲明類型盡量是抽象類或接口。

3). 使用繼承時遵循裡氏替換原則。

接口隔離原則

定義：用戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。

應當為用戶端提供近可能小的單獨的接口，而不是提供大的總接口。

1). 使用多個專門的接口比使用單一的總接口要好。

2). 一個類對另外一個類的依賴性應當是建立在最小的接口上的。

3). 一個接口代表一個角色，不應當将不同的角色都交給一個接口。沒有關系的接口合并在一起，形成一個臃腫的大

接口，這是對角色和接口的污染。

4). “不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結構。”

這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，如果強迫使用者使用它們不使用的方法，那麼這

些客戶就會面臨由于這些不使用的方法的改變所帶來的改變。

迪米特原則

定義：一個對象應該對其他對象保持最少的了解。

顯然，接口隔離原則與廣義的迪米特原則都是對一個軟體實體與其他的軟體實體的通信的限制。廣義的迪米特原則要

求盡可能限制通信的寬度和深度。接口隔離原則所限制的是通信的寬度，也就是說，通信應當盡可能地窄。

迪米特法則又叫最少知道原則，最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講，就

是一個類對自己依賴的類知道的越少越好。也就是說，對于被依賴的類來說，無論邏輯多麼複雜，都盡量地的将邏輯

封裝在類的内部，對外除了提供的public方法，不對外洩漏任何資訊。迪米特法則還有一個更簡單的定義：隻與直接

的朋友通信。首先來解釋一下什麼是直接的朋友：每個對象都會與其他對象有耦合關系，隻要兩個對象之間有耦合關

系，我們就說這兩個對象之間是朋友關系。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變

量、方法參數、方法傳回值中的類為直接的朋友，而出現在局部變量中的類則不是直接的朋友。也就是說，陌生的類

最好不要作為局部變量的形式出現在類的内部。

開閉原則

一個軟體實體應當是對擴充開放，對修改關閉。

組合/聚合複用原則

要盡量使用組合/聚合，而不是繼承關系達到複用的目的。