以下是我對Design pattern初步的理解，所以如果有錯敬希指正。
類別與物件
類別與物件是物件導向中的基礎概念，所以先複習一下。
“An Object is anything to which a concept applies. It is an instance of a concept.” — J.Martin & J.Odell, Object-Oriented Methods: Principles and Practice
類別與物件的定義
類別(Class)是一種型態，沒有實體。
物件(Object)是一個實體，是類別的具體形象，或者說是類別的展現。
麻瓜版 像我們真實世界一樣，類別是抽象的概念；而物件是真實存在、看得見摸得到的東西。
文組版 如果跟我一樣是文組出身的話，可以用《易經》的「形而上者謂之道，形而下者謂之器」去理解，類別就是道，物件就是器。
類別與物件的分別
除了是不是實體外，類別與物件還有以下分別：
- 要先定義類別才能new object
在真實世界中，我們先有物件再有類別，但在記憶體的世界是先有類別再有物件，因為物件是按類別打造出來的東西。 - 記憶體
類別變數/方法不需要 new 就會先佔用固定的一份記憶體空間。
物件new object時才會分配記憶體去儲存物件資料與活動時的狀態。 - 屬性/方法的使用條件
類別屬性/方法不需要產生實例，即可使用。
實例屬性/方法一定要等到實例產生（東西存在了）之後才有實質的存在，因此需要實例才可以使用。 - 物件可以用類別方法而類別不能用實例方法
類別只能存取類別屬性/方法，因為實例沒有生出來，所以類別方法不能用實例屬性
類別與物件之間的關聯
物件是按類別打造出來的東西，所以類別是物件的架構與行為的範本，但物件可按大原則作出變化。
文組版 我們都知道所謂「道」是「高於形」，是萬物運動變化的法則；「形而下」是指作為具體存在、按道去運行的萬物。
類別圖與物件圖
不是討論重點所以不詳談
- 類別圖（Class Diagram）和物件圖（Object Diagram）是UML 圖的其中兩種
- 類別圖描述了類別的型態、屬性和方法，同時也表達了類別之間的靜態關係(static relationship)。跟類別圖的差別是物件圖描述的是實例之間的關係。
- 斜體字的類別名稱代表抽象類別（Abstract Class）
- 類別圖中不同箭頭代表不同的類別關係：
更多參考：[設計模式]-UML類圖的各符號含義
設計原則
有SOLID+迪米特法則共六項基本原則：
單一職責原則(SRP, Single Responsibility Principle)
實作類別職責單一
最極致就是一個class只做一件事，只有一個public method，但通常都不會。
開放/封閉原則(OCP, Open/Close Principle)
對擴展開放，對修改封閉
當需求變更時，在不改變現有程式碼的前提之下，藉由增加新的程式碼來實作新的功能，而並非修改程式增加功能。
只有一個情況下會修改程式 — 就是程式碼的邏輯有錯。
Liskov替換原則(LSP, Listov Substitution Principle)
不要破壞繼承體系
子類應該要可以替換掉父類，而不會影響程式。
介面隔離原則(ISP, Interface Segregation Principle)
介面實作要精簡
只接會用到的介面，用最少的方法去完成最多的事。
依賴反轉原則(DIP, Dependency Inversion Principle)
對著介面寫程式
"Program to an interface, not an implementation."
物件和物件不應該相互相依，而是要依賴於抽象層(相對於實例，抽象層要穩定得多)
當有會重複使用到的行為，不要讓一個物件參考另一個物件，要在物件之間增加抽象層（介面），讓物件依賴於抽象層，所以是針對介面寫程式，而不是實例。
迪米特法則(LoD, Law of Demeter)
物件應對其他物件有最少的了解
對自己所依賴的類別/物件知道得越少越好。
23種行為模式留待下回分解。
