前言:設計模式幾乎是程序員必修的一門課程,而能夠深入理解和運營設計模式更是程序員向架構師進階的必備技能。但是,實際上,很多人對設計模式的理解僅僅停留在表面,甚至還因爲代碼中使用了設計模式而洋洋自得——而根本不管這是否必要!
理解GOF(Gang of Four,指撰寫《設計模式》的四位作者)設計模式對於程序員而言是十分有價值的。當然,相對於理解,大部分設計模式的擁躉看起來僅僅是使用他們。甚至,在有些時候過度使用。
Java的Spring框架其中臭名昭著的一點是充斥着類似SimpleBeanFactoryAwareAspectInstanceFactory名稱的類。至於其中命名是否簡便性和設計模式是否正確運用這個由讀者自己評判,但是就我本人而言,是十分討厭看到這樣的東西的。
設計模式可以拆分爲四個大的類型:行爲型、結構型、並行型和創建型。創建型,如同名稱所示,是講述如何編寫創建各類對象實例的代碼,例如工廠類。這是用於編寫可複用、可測試和模塊化代碼的合集。大部分依賴注入(DI)和控制反轉(IOC)框架是應用了創建型的設計模式。
然而,這給人造成了直接調用構造函數創建對象的方式是很Low的錯誤印象。例如,Emiko就發現瞭如下的Java代碼:
/**
* Creates an empty {@link MessageCType}.
* @return {@link MessageCType}
*/
public static MessageCType createMessage() {
MessageCType retVal = new MessageCType()
return retVal;
}
這僅僅是一個替換構造函數的方法,類似的代碼就像成堆的垃圾一樣在項目裏隨處可見。如果是他們把這個方法應用於流式編程中創建對象的話還情有可原。然而……他們並沒有,實際上最終的調用代碼是這樣的:
MessageCType msg = MessageCType.createMessage();
msg.type = someMessageType;
msg.body = …
由此,Emiko總結到:“在工作中,我們顯然在爲自己使用了高大上的設計模式而感到自豪!”