九大設計原則

NO IMAGE

封裝變化

“找出應用中可能需要變化之處,把它們獨立出來,不要和那些不需要變化的程式碼混在一起。”

        換句話說,如果每次新的需求一來,都會使某方面的程式碼發生變化,那麼你就可以確定,這部分的程式碼需要被抽出來,和其他穩定的程式碼有所區分。

單一職責原則

“一個類應該只有一個引起變化的原因。”

        類的每個責任都有改變的潛在區域。超過一個責任,意味著超過一個改變的區域。這個原則告訴我們,儘量讓每個類保持單一責任。當一個模組或一個類被設計成只支援一組相關的功能時,我們說它具有高內聚;反之,當被設計成支援一組不相關的功能時,我們說它具有低內聚。內聚是一個比單一責任原則更普遍的概念,但兩者其實關係是很密切的。遵守這個原則的類容易具有很高的凝聚力,而且比揹負許多責任的低內聚類更容易維護。

        單一職責原則可以看作是低耦合、高內聚在物件導向原則的引申,將職責定義為引起變化的原因,以提高內聚性,減少引起變化的原因。

開放-關閉原則

“類應該對擴充套件開放,對修改關閉。”

        一個軟體實體(如類、模組和函式)應該對擴充套件開放,對修改關閉。意思是在一個系統或者模組中,對於擴充套件是開放的,對於修改是關閉的。一個好的系統是在不修改原始碼的情況下,可以擴充套件你的功能。這樣的設計具有彈性,可以應對改變,可以接受新的功能來應對改變的需求。而實現開閉原則的關鍵就是抽象化。

里氏替換原則

“任何基類可以出現的地方,子類一定可以出現。”

        這一思想表現為對繼承機制的約束規範,只有子類能夠替換其基類時,才能夠保證系統在執行期內識別子類,這是保證繼承複用的基礎。所有引用基類(父類)的地方必須能透明地使用其子類的物件。即子類必須能夠替換基類出現的地方,子類也能在基類的基礎上新增行為。

介面隔離原則

“客戶端不應該依賴那些它不需要的介面。”

        一旦一個介面太大,則需要將它分割成一些更細小的介面,使用該介面的客戶端僅需要知道與之相關的方法即可。

依賴倒置原則

“要依賴抽象,不要依賴具體類。”

        不能讓高層元件依賴低層元件,而且,不管高層或低層元件,“兩者”都應該依賴於抽象。要針對介面程式設計,不針對實現程式設計。

合成/聚合複用原則

“儘量使用合成/聚合,而不是繼承關係來達到軟體複用的目的。”

        使用組合建立系統具有很大的彈性,不僅可將演算法族封裝成類,更可以“在執行時動態地改變行為”,只要組合的行為物件符合正確的介面標準即可。

        也就是說,在一個新的物件裡面使用一些已有的物件,使之成為新物件的一部分;新物件通過向這些物件的委派達到複用已有功能的目的。

迪米特法則

“只和你的密友談話。”

        迪米特法則又稱最少知識原則,它告訴我們要減少物件之間的互動,只留下幾個“密友”。當你正在設計一個系統,不管是任何物件,你都要注意它所互動的類有哪些,並注意它和這些類是如何互動的。這個原則希望我們在設計中,不要讓太多的類耦合在一起,免得修改系統中一部分,會影響到其他部分。如果許多類之間相互依賴,那麼這個系統就會變成一個易碎的系統,它需要花許多成本維護,也會因為太複雜而不容易被其他人瞭解。

        每一個軟體單位對其他的單位都只有最少的知識,而且侷限於那些與本單位密切相關的軟體單位。也就是說,一個物件應當對其他物件有儘可能少的瞭解。一個類應該對自己需要耦合或呼叫的類知道得最少,你(被耦合或呼叫的類)的內部是如何複雜都和我沒關係,那是你的事情,我就知道你所提供的方法,我就呼叫這麼多,其他的一概不關心。

好萊塢法則

“別呼叫我們,我們會呼叫你。”

        好萊塢原則可以給我們一種防止“依賴腐敗”的方法。當高層元件依賴低層元件,而低層元件又依賴高層元件,而高層元件又依賴邊側元件,而邊側元件又依賴低層元件時,依賴腐敗就發生了。在這種情況下,沒有人可以輕易地搞懂系統是如何設計的。在好萊塢原則下。我們允許低層元件將自己掛勾到系統上,但是高層元件會決定什麼時候和怎樣使用這些低層元件。換句話說,高層元件對待低層元件的方式是“別呼叫我們,我們會呼叫你”。

參考資料:[1](美)弗里曼(Freeman,E.).Head First設計模式(中文版)[M].北京:中國電力出版社,2007.9