設計模式與系統階段

banq發表於2014-10-21
我們經常碰到一個問題:母親和老婆掉到水裡,你先救哪個?這個問題很難回答,我們從GOF設計模式與系統的角度來解剖這個問題。

GOF設計模式分三種型別:結構型、建立型和行為型,這三者型別其實對應著一個系統的三個階段:設計階段、建立階段和執行階段。

結構型模式指出如何設計出系統的結構,也就是一個系統的孕育,如同人的十月懷胎過程。

建立型模式指出系統起初如何被建立,也就是宇宙大爆炸前一刻,是系統從紙上落地,如同人的出生和養育,是從無到有的建立過程。

行為型模式是針對系統建立後進入自我執行階段,這時再也無需建立者和設計者干預,如同人的成年結婚生子。也就是宇宙形成後的執行狀態。

下面進入具體論證一下:
(1)結構型模式有Facade Proxy 橋模式 介面卡Adapter和組合模式等等,這些模式共同點是針對程式碼結構如何設計,比如介面卡模式是設計出一個適配類,能夠將原來兩個不匹配的類能夠和諧統一,結構上可能有三個類,一般結構關係可以使用UML的類圖表達;組合模式更是一種程式碼結構組合,將兩個類組合在一起;這是一種組成結構的關係。

有結構就有關係,這也是關聯式資料庫為什麼能表達結構一樣,設計表結構Schema實際是設計結構關係。

在建築領域,土木結構的設計需要精確的設計階段,建築繪圖就是一種結構或架構設計,它類似我們的結構型模式。

(2)建立型模式有工廠模式等,建立模式指出一個系統從設計圖紙到落地執行如何建立的過程,正如一個建築從圖紙到落成需要經過施工建立過程一樣。工廠模式指出專門有一個工廠類負責類的建立。

(3)行為型模式有Command 職責鏈 觀察者等模式,這些模式都是針對系統進入自執行階段時,系統內部如何執行的,比如Command模式是指從客戶端發出請求打包成一個命令,由後端根據命令指派相應的模組響應處理。而職責鏈類似於過濾器,可以對請求命令進行一個個過濾攔截;觀察者模式則是對執行時的狀態改變的及時響應,發展為後來的Reactor模式或非同步模式,因為非同步程式設計是針對系統執行階段的程式設計,編碼時需要聯想到系統執行的狀態,這對於沒有系統執行經驗的程式設計師比較難,一般程式設計師比較適合順序程式設計,順序程式設計是一種結構程式設計,那麼現在我們提供一些框架能讓順序程式設計的程式碼在執行時非同步執行,這些都是在認識到系統不同階段的邊界後才有的發展。

因此,認識到一個系統有不同的邏輯邊界對於我們認識世界更加重要,系統的結構設計、建立階段和執行階段是三個嚴格不同的邏輯世界,如同天上 人間和地獄三界不同一樣。

有了系統邊界認識,對於解答本文開始的問題就非常容易,母親和老婆掉水救哪個?母親是建立養育自己,而老婆是自己成年後進入自執行生活階段的重點,母親屬於建立者,是建立階段的重點,而老婆是執行階段的重點,將這兩個重點跨域邊界比較顯然是不符合邏輯的,提這個問題的人沒有系統邏輯分界。

再比如:老闆大還是公司規章制度大?老闆確實是公司制度的制定者,實際屬於建立階段的老大,但是制度一旦頒佈,進入執行階段,老闆自己也要服從制度管理,這時是制度大。

還有一個經濟學問題,經濟中重要兩個角色,一個商品需要生產者和消費者,那麼生產者重要還是消費者重要呢?過去計劃經濟時期,我們抓生產,結果經濟還是沒有抓上去,國營的一個個生產廠家都倒閉了,其實還是沒有從系統階段邊界來認識這個問題,生產者屬於經濟系統建立階段的老大,只有大量建立生產工廠,才能建立出各種商品;但是當經濟進入自執行階段後,供大於求,經濟還是會崩潰,這時消費者就是老大了,只有消費才是驅動經濟的關鍵,這也是凱恩斯等經濟理論的核心基礎,也就是為什麼西方國家鼓勵貸款提前消費的邏輯基礎。

扯了這麼多鹹蛋,主要是想說明,其實設計模式不只是對於程式設計有作用,而且對於自己的三觀也有幫助,因為開發者開發出一個軟體系統,麻雀雖小,五臟俱全,其基本原理不亞於上帝創造世界。如果一個程式設計師只知道資料結構和演算法,卻對一個系統的設計 建立和執行等階段沒有基本邏輯認識,那麼很顯然會迷失在細節中失去方向。

從老子有無哲學觀點看:資料結構演算法和功能屬於“有”,看得見摸得著;而系統階段邊界屬於“無”,雖然無形無態,但是自然之道是無生有,我們不能因為首先學習了有形的知識,卻忽視了無形的思想。

[該貼被banq於2014-10-21 09:43修改過]

相關文章