以下是我對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種行為模式留待下回分解。