重讀《Head First 設計模式》之一 軟體設計原則

軟體開發的一個不變真理

不管當初的軟體設計得有多好，一段時間之後，總是需要成長與改變，否則軟體就會“死亡”。

設計原則一

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

把會變化的部分取出來并封裝起來，讓系統中的某部分改變不會影響其他部分，代碼變化引起的不經意後果變少，系統變得更有彈性。

設計原則二

針對接口程式設計，而不是針對實作程式設計

“針對接口程式設計”真正的意思是“針對超類型（supertype）程式設計”，關鍵就在多态，利用多态，程式可以針對超類型程式設計，執行時會更具實際的狀況執行到真正的行為，不會綁死在超類型的行為上，更明确的說，變量的聲明類型應該是超類型，通常是一個抽象類或者一個接口，隻要是具體實作此超類型的類所産生的的對象，都可以指定給這個變量，這樣聲明類時不用理會以後執行的真正對象類型。

設計原則三

多用組合，少用繼承

使用組合建立系統具有很大的彈性，不僅可将算法封裝成類，還能在組合的行為對象符合正确的接口标準時“在運作時動态的改變行為”。

設計原則四

為了互動對象之間的松耦合設計而努力。

松耦合的設計之是以能讓我們建立有彈性的系統，能夠應對變化，是因為對象之間的互相依賴降到了最低。

設計原則五

類應該對擴充開發，對修改關閉

設計的目标是允許類容易擴充，在不修改現有的代碼的情況下，就可以搭配新的行為。這樣的設計具有彈性可以應對改變，可以接受新的功能來應對改變的需求。

設計原則六

要依賴抽象類，不要依賴具體類

不能讓高層元件依賴低層元件，不管高層或低層元件，“兩者”都應該依賴于抽象。

變量不可以隻有具體類的引用，不要讓類派生自具體類，不要覆寫基類中已實作的方法。

設計原則七

最少知識原則(迪米特法則)：隻和朋友通信，不和陌生人說話

在設計系統時，不管任何對象都要注意它所互動的類有哪些，并注意它和這些類是如何互動的，不要讓太多的類耦合在一起，如果許多類之間互相依賴，它需要花許多成本維護，且這個系統會變成一個易碎的系統。

設計原則八

好萊塢原則：别調用（打電話給）我們，我們會調用（打電話給）你

好萊塢原則給我們一種防止“依賴腐敗”的方法，我們允許低層元件将自己挂鈎到系統上，但是高層元件會決定什麼時候和怎樣使用這些低層元件。

設計原則九

單一責任：一個類應該隻有一個引起變化的原因

如果一個類具有兩個改變的原因，那麼這會使得該類的變化幾率上升，當一個類被設計成隻支援一組相關功能時，它具有高内聚，高内聚的類比背負組多責任的低内聚類更容易維護。