設計模式與形式主義，我的胡思亂想 (轉)

設計模式與形式主義，我的胡思亂想 (轉)[@more@]

1年半前寫的，對比著看看，現在好像自己成熟一些了:)

softarts@elong.com

7月13日到上海,16日開始上班,到現在將近兩個月了,感覺還是挺充實的,甚至有點累,可能是我給自己加了太多的任務,定下太高的目標,真的好累,我決定要好好休息一段時間,順便把個人主頁一下,否則chinaren就要把我踢出去了.

其實今年以來一直沒怎麼寫程式碼，也就是上半年3月-4月之間寫過一段時間，東西都忘得差不多了。基礎不牢的後果很快體現出來，以前圖方便一般用的是MFC，好多的特性都是一知半解甚至一點都不清楚，上個月開始重新用VC++的時候真有點一籌莫展的感覺，程式碼改來改去，總是不理想或存在，那個時候我很想去買一本houjie寫的《MFC深入淺出》徹底學學MFC的，後來一想算了，MFC即使還沒有到滅亡的時候，我現在也對WINDOWS環境下的深惡痛絕，我渴望能在一個非常自由的環境下做一些貼近底層的、有挑戰性的工作，而不僅僅是懂得搭積木式的coding，於是我打消了買書的念頭，老老實實的捧著《Thinking in C++》看了起來。

前不久認識了一位在公司工作了三年的朋友，他也是一位coding好手，有一次和他討論內部各個模組如何組織的問題，收穫挺大的。

先說我的看法吧，今年初我開始持一種在中採用類似於MS DNA結構開發的觀點，把軟體內部的各個模組分為表現層，邏輯層，資料層（注意：我說的只是一個軟體內部各個C＋＋類的組織形式，而不是一個大型方案的結構，大型系統方案當然都會採用三層結構），這是當時我看三星的基站網管軟體文件忽然得來的一個想法。那時候我挺激動的，想著自己經歷了一年多的coding生活，總算由量變到達質變，我先是在水木清華軟體工程版或者是VISUAL C++版或者是Programming版上丟擲這個論點，馬上有網友響應我這個觀點，後來好像還收進了精華區（hehe，記不清了，找不到不要罵我哦），然後我開始動手把去年底在教研室做的一個GPS-GSM車載終端軟體按照這個思路重寫一遍，把所有的邏輯處理從各種各樣的View/Wnd/FrameWnd裡抽離出來，形成寫成一個個專用於邏輯處理的類，與有關的則被我歸結到資料層上去，與介面有關的當然就是表現層了，這樣一來，整個軟體結構顯得清晰很多，程式碼易讀很多。

寫完那個軟體之後，我對這個想法愈加深信，我開始全面的在自己的軟體開發中通盤考慮這種做法，甚至有些過了頭走向極端。有一段時間，我無論拿到什麼樣的project都要從三層上來考慮，A層負責與使用者互動，B層負責邏輯處理，C層負責資料儲存，幾個邏輯模組B1，B2，B3之間還存在一個通訊佇列，B1負責寫佇列，B2負責讀佇列......一開始我就把一個小軟體的設計得非常龐大嚇人，到了動手開始寫程式碼後，我發現自己漸漸無法控制程式碼了，儘管開始我認為自己的軟體結構定的很好了，但還是有很多意想不到的事情，一方面是實際情況很複雜，並不是我設計那麼幾個表現層、邏輯層、資料層所能解決的；另一方面是過於追求模式，什麼樣的東西都往三層上套，一個很小的功能，一個類就能解決的，我很硬性的分為兩/三層結構，用了好幾個類，儘管每個類只有一兩個，而且這幾個類之間的功能並不象所謂的三層那樣區別非常明顯......我熱衷於模式設計，卻陷入了形式主義。

有天晚上，我把自己的這個想法和那位同事交流了一下，他和我的想法差別較大，在軟體內部模組組織上，他不象我那樣非要以某種模式來組織軟體，他並不看重軟體內部模組劃分的是否鮮明，他只是講究某個類所實現的功能具備好的內聚性和耦合性，比如一個屬性表，要是以我的想法，必定是一個專管邏輯處理的類，負責判斷使用者設定了那些屬性，把這些屬性儲存到那個設定檔案中，然後再把結果返回到表現層以反饋給使用者；而我的同事的想法非常直接，就是一個類，既用於介面表現又用於邏輯處理，他認為這個類的最小功能單位就是這個，沒必要再分了。又比如我寫了一個顯示實時曲線的模組，需要把它給別的使用者用，我的第一想法就是隻給使用者一個邏輯介面，負責計算座標，新增實時資料，然後使用者要透過這個介面去繪圖，不再另外給使用者與表現層的介面繪圖，我的理由是介面功能統一便於程式設計。我的同事對此表示不解，他認為，這個功能模組就是一個實時曲線視窗，讓使用者直接從這個視窗類派生出自己的類，使用者想幹什麼就幹什麼，這樣更好。

我開始有點贊同他的想法了，我覺得自己的問題在於有時把軟體劃分的過於複雜，軟體設計的目的之一在於劃分好清晰的功能模組，而我卻為了所謂的模式把功能分得過細，七零八落的，我們開發的目的是實現軟體的功能而不是為了設計模式。不過話又說回來，我覺得這可能是另一方面的原因，並不一定是自己追求設計模式的錯，再過一段時間，一年或者兩年，再回過頭看看，也許認為這種做法是對的，這種模式是對的，只不過自己在編碼上不足。我一直認為，一個成功的軟體就是應該在設計階段嚴謹、規範、全面，框架定的大，正表明考慮周到，目前遇到這麼多的問題只是因為經驗有限，或者說這是必然的，我想經驗再豐富的編碼人員也不可能面面俱到。

今天寫了好多，文章太長了，下一次再寫。