設計模式

概念

模式是在某種情景下(Context)下，針對某問題的設計的某種解決方案。

• 情景：是應用某個模式的情況。這應該是會不斷出現的情況。
• 問題：是你想在某情景下達到的目標，但也是某種情景下的約束
• 解決方案：是你所求的一個通用的設計，可用來解決約束，達到目標。

分類

模式可以分為以下三種不同的類別：建立型、行為型和結構型。

• 建立型：建立型模式涉及到物件例項化，這類模式都提供一個方法，將客戶從所需要的例項化物件中解耦。
• 行為性：只要是行為行為設計模式，都涉及到類和物件如何互動以及分配職責。行為設計模式的目的——物件之間的溝通與互聯。
• 結構性：結構性設計模式可以讓你把類或者物件組合到更大的結構中。結構型模式用來描述類和物件如何被組合以建立新的結構或者新的功能。

分類細則

• 二、建立型
  • 1. 單例（Singleton
  • 2. 簡單工廠（Simple Factory）
  • 3. 工廠方法（Factory Method）
  • 4. 抽象工廠（Abstract Factory）
  • 5. 生成器（Builder）
  • 6. 原型模式（Prototype）
• 三、行為型
  • 1. 責任鏈（Chain Of Responsibility）
  • 2. 命令（Command）
  • 3. 直譯器（Interpreter）
  • 4. 迭代器（Iterator）
  • 5. 中介者（Mediator）
  • 6. 備忘錄（Memento）
  • 7. 觀察者（Observer）
  • 8. 狀態（State）
  • 9. 策略（Strategy）
  • 10. 模板方法（Template Method）
  • 11. 訪問者（Visitor）
  • 12. 空物件（Null）
• 四、結構型
  • 1. 介面卡（Adapter）
  • 2. 橋接（Bridge）
  • 3. 組合（Composite）
  • 4. 裝飾（Decorator）
  • 5. 外觀（Facade）
  • 6. 享元（Flyweight）
  • 7. 代理（Proxy）

設計原則

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

把會變化的部分取出並封裝起來，以便以後可以輕易地改動或擴充此部分，而不影響不需要變化的其他部分。

2. 針對介面程式設計，而不是針對實現程式設計

"針對介面程式設計"真正地意思是“針對超型別(supertype)程式設計”。可以更明確的說成“變數的宣告型別應該是超型別，通常是一個抽象類或者是一個介面”

3. 多用組合，少用繼承

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

4. 為了互動物件之間的鬆耦合設計而努力

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

5. 類應該對擴充套件開發，對修改關閉

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

6. 要依賴抽象，不要依賴具體類（依賴導致原則）

不能讓高層元件依賴於低層元件，而且，不管高層元件還是底層元件，“兩者”都應該依賴於抽象。

7. 最少知識原則：只和你的密友談話

不要讓太多的類耦合在一起，免得修改系統中的一部分，會影響到其他部分。如果許多類相互依賴，那麼這個系統就會變成一個易碎的系統，他需要花許多成本維護，也會因為太複雜而不容易被其他人瞭解。

8. 好萊塢原則：別調用（打電話）我們，我們會呼叫(打電話給)你。

在好萊塢原則下，我們允許底層元件將自己掛鉤到系統上，但是高層元件會決定什麼時候和怎樣使用這些底層元件。換句話說，高層元件對待底層元件的方式是”別調用我們，我們會呼叫你們“。

9. 單一責任原則：一個類應該只有一個引起變化的原因。

我們知道要避免類內的改變，因為修改程式碼很容易造成許多潛在的錯誤。如果有一個類具有兩個變化的原因，那麼這會使得將來該類的變化機率上升，而當它正在改變的時候，你的設計中同時又兩個方面講會受到影響。