《Head.First-Design.Patterns》總結

設計原則


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

針對接口編程，而不是針對實現編程
（針對超類型編程，變量的聲明類型應該是超類型，通常是一個抽象類或者是一個接口）


多用組合，少用繼承


爲了交互對象之間的鬆耦合設計而努力


類應該對擴展開放，對修改關閉


依賴倒置：要依賴抽象，不要依賴具體類（當你直接實例化一個對象時，就是在依賴它的具體類）
不要讓高層組件依賴低層組件，而且，不管高層或低層組件，兩者都應該依賴於抽象


最少知識原則：只和你的密友談話（任何對象只應該調用屬於以下範圍的方法：該對象本身，
被當做方法的參數而傳遞進來的對象，此方法所創建或實例化的任何對象，對象的任何組件）


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


單一責任（內聚）：一個類應該只有一個引起變化的原因


設計模式


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

觀察者模式：定義了對象之間的一對多依賴，這樣一來，當一個對象改變其狀態時，
它的所有依賴者都會收到通知並自動更新


裝飾者模式：動態地將責任附加到對象上，若要擴展功能，裝飾者提供了比繼承更有
彈性的替代方案


工廠方法模式：定義了一個創建對象的接口，但由子類決定要實例化的類是哪一個；
工廠方法讓類把實例化推遲到子類


抽象工廠模式：提供一個接口，用於創建相關或依賴對象的家族，而不需要明確指定具體類


單件模式：確保一個類只有一個實例，並提供一個全局訪問點


命令模式：將“請求”封裝成對象，以便使用不同的請求、隊列或者日誌來參數化其他對象；
命令模式也支持可撤銷的操作


適配器模式：將一個類的接口，轉換成客戶期望的另一個接口
適配器讓原本接口不兼容的類可以合作無間


外觀模式：提供了一個統一的接口，用來訪問子系統中的一羣接口
外觀定義了一個高層接口，讓子系統更容易使用


模板方法模式：在一個方法中定義一個算法的骨架，而將一些步驟延遲到子類中
模板方法使得子類可以在不改變算法結構的情況下，重新定義算法中的某些步驟


迭代器模式：提供一種方法順序訪問一個聚合對象中的各個元素，而又不暴露其內部的表示


大師
建立可維護的OO系統，要訣就在於隨時想到系統以後可能需要的變化以及應付變化的原則


代碼應該如同晚霞中的蓮花一樣地關閉（免於改變），如同晨曦中的蓮花一樣地開放（能夠擴展）


實現一個接口 泛指 實現某個超類型（可以是類或接口）的某個方法


裝飾者可以在所委託被裝飾者的行爲之前或之後，加上自己的行爲，以達到特定目的


工廠方法使用繼承：把對象的創建委託給子類，子類實現工廠方法來創建對象


工廠方法把客戶代碼從需要實例化的具體類中解耦


抽象工廠使用對象組合：對象的創建被實現在工廠接口所暴露出來的方法中


抽象工廠創建相關的對象家族，而不需要依賴它們的具體類


抽象工廠的方法經常以工廠方法的方式實現


如果程序有多個類加載器又同時使用了單件模式，需要自行指定同一個類加載器


命令模式的更多用途：隊列請求、日誌請求


對象適配器和類適配器使用兩種不同的適配方法，分別是組合和繼承


類適配器不是使用組合來適配被適配者，而是繼承被適配者和目標類（Java不支持多繼承）


裝飾者：不改變接口，但加入責任


適配器：將一個接口轉成另一個接口


外觀：讓接口更簡單


外觀和最少知識原則


好萊塢原則和模板方法


好萊塢原則和依賴倒置原則


P353/697