讀書筆記：《HeadFirst設計模式》

隻是一些看書時的簡單筆記，不定期更新

最後一次更新：2018-07-09

OO基礎

抽象、封裝、多态、繼承

OO特性

可複用、可擴充、可維護

設計原則

• 封裝變化
  • 找出應用中可能需要改變之處，把它們獨立出來，不要和那些不需要改變的代碼混在一起。
  • 把會變化的部分取出并封裝起來，以便以後可以輕易地改動或擴充此部分，而不影響不需要改變的其他部分。
  • 系統中的某部分改變不會影響其他部分。
• 針對接口程式設計，而不是針對實作程式設計。
• 多用組合，少用繼承。
• 為了互動對象之間的松耦合設計而努力。
• 對擴充開放，對修改關閉。
• 依賴抽象，不要依賴具體類 。
• 最少知識原則：隻和你的密友談話。

設計模式

• 政策模式（Strategy Pattern）

  定義了算法族，分别封裝起來，讓它們之間可以互相替換，此模式讓算法的變化獨立于使用算法的客戶。

• 觀察者模式（Observer）

  定義了對象之間的一對多依賴，這樣一來，當一個對象改變狀态時，它的所有依賴者都會收到通知并自動更新。

• 裝飾者模式（Decorator）

  動态地将責任附加到對象上。若要擴充功能，裝飾者提供了比繼承更有彈性的替代方案。

• 工廠模式（Factory）
  • 簡單工廠（Simple Factory）

    這其實是一種程式設計習慣而非設計模式：将執行個體化哪一個類的操作移到單獨的一個類中，形成工廠和客戶的關系。

  • 工廠方法模式（Factory Method）

    定義了一個建立對象的接口，但由子類決定要執行個體化的類是哪一個。工廠方法讓類把執行個體化推遲到子類。

  • 抽象工廠模式（Abstract Factory）

    提供一個接口，用于建立相關或依賴對象的家族，而不需要明确指定具體類。

• 單件模式（Singleton Pattern）

  用來建立獨一無二的，隻能有一個執行個體的對象。

• 指令模式

  将“請求”封裝成對象，以便使用不同的請求、隊列或者日志來參數化其他對象。指令模式也支援可撤銷的操作。

• 擴充卡模式

  将一個類的接口，轉換成客戶期望的另一個接口。擴充卡讓原本的接口不相容的類可以合作無間。

• 外觀模式

  提供了一個統一的接口，用來通路子系統中的一群接口。外觀定義了一個高層接口，讓子系統更容易使用。

• 模闆方法模式

  x

• 疊代器與組合模式

  x

• 狀态模式

  x

• 代理模式

  x

• 複合模式

  x

• 橋接模式（Bridge）

  概述：使用橋接模式不隻改變你的實作，也改變你的抽象。

  意圖：将抽象部分與它的實作部分分離，使它們都可以獨立地變化。

其他

• 松耦合

  當兩個對象之間松耦合，它們依然可以互動，但是不太清楚彼此的細節。

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

腦圖位址：Process On

腦圖預覽

##《HeadFirst設計模式》電子版：下載下傳位址

##設計模式使用率排行（轉）

使用頻率	所屬類型	模式名稱	模式
5	建立型	Singleton	單件
5	結構型	Composite	組合
5	結構型	FACADE	外觀
5	結構型	Proxy	代理
5	行為型	Iterator	疊代器
5	行為型	Observer	觀察者
5	行為型	Template Method	模闆方法
4	建立型	Abstract Factory	抽象工廠
4	建立型	Factory Method	工廠方法
4	結構型	Adapter	擴充卡
4	結構型	Decrator	裝飾
4	行為型	Command	指令
4	行為型	State	狀态
4	行為型	Strategy	政策
3	建立型	Builder	生成器
3	結構型	Bridge	橋接
3	行為型	China of Responsibility	職責鍊
2	建立型	Prototype	原型
2	結構型	Flyweight	享元
2	行為型	Mediator	中介者
2	行為型	Visitor	通路者
1	行為型	Interpreter	解釋器
1	行為型	Memento	備忘錄