人們都善於用直觀簡單的方式來理解事物,我也堅信,所有優秀的解決方案都是直觀而簡單的,我喜歡直觀而簡單的解決方案,也許在找到直觀簡單的解決方案之前,我們已經嘗試了用很多複雜費解的方式來解決問題。如果你不能把我們程式的解決方案用通俗易懂的方式給隔壁賣青菜的阿伯解釋清楚的話,說明,這個解決方案還不夠好――還不夠簡單和直觀。宇宙夠複雜了吧,可是霍金卻創作《時間簡史》系列的科普讀物,既然是科普,它的讀者就是廣大的普通老百姓,不一定非要是物理學或天文學的博士。
在軟體解決方案上,為了追求直觀而簡單的解決方案,我們發明了物件導向,之後又是N層架構、面向組件、AOP,又到現在比較熱門的MDA、WebService等等。我們所做的一切,都是為了將複雜的問題簡單化,這個過程是一個進化的過程,隨著這個過程的演化,事物越來越接近它自己的本質。比如,將資料和操作資料的動作放在一起變成了類,這樣,各個類之間就有了界限,就像自然界中的一個個獨立的實體,這就向事物的本質靠近了一步。在類的基礎上,我們又根據共同的語義將共同的行為剝離出來,形成介面,這就像自然界中的生物的系/族,這向事物的本質又靠近了一步。整個自然界或者說整個人類社會最美好的未來在於每個個體都能規範自己的行為,都能自己管理自己,對自己的行為負責,友好地向外界發布自己的資訊。這個個體不就是一個優秀設計的類嗎?為了這個美好的未來,我們為類加入了屬性和事件,以使其在發布自己資訊的同時,不對外界的其它個體產生幹擾;我們為類加入中繼資料和反射能力,使其和外界都能方便的得到自己詳細身份資訊。再後來,我們將業務與基礎服務分離(所謂基礎服務就是像事務、安全執行緒等內容),將業務與基礎服務分離有很多好處,首先基礎服務可以在不同的項目/應用中複用,這通常可以通過AOP或組件的方式進行複用;其次,業務和基礎服務分離開後,它們之間的關係更清晰,我們更容易將焦點集中到業務上,這也會使事情變得更簡單,因為我們不用在實現某一商務邏輯的時候還需要考慮在什麼地方插入加鎖代碼來確保這個邏輯是安全執行緒的。
我們應該都有這樣的經曆,在對多線程、網路、資料庫這些基礎服務都不熟悉的時候,編寫一個應用伺服器,難度會是多大?我們經常都是不知如何下手,更別談什麼結構設計了。在我們慢慢的熟悉這些概念並實踐了多次之後,我們就有信心來實現我們應用程式的業務功能。如果現在我們完全不用關心這些基礎服務,只需關心商務邏輯,那麼我們的信心不就是更大了嗎?這是因為我們能有更多的精力去分析理解我們的業務,對我們的業務分析的越透徹,我們的設計就會越直接、越簡單。這就是我們的目標。
為了獲得簡單直接的設計,我們通常要注意以下幾個方面:
(1)組件之間的耦合度小。每個組件應該自解釋、自描述、並且是自給自足的。
(2)類圖簡單。請注意類的體積,把太龐大的類分解為多個,把耦合太緊的類融合為一個。
(3)互動圖簡單。
(4)使用合適的設計模式。能沉澱下來的總是精華!
(5)重構、重構、再重構……,這是我最大的法寶!!!