《設計模式——基於C#的工程化實現及擴充》

 

作者訪談錄

 

針對王翔老師的新書《設計模式——基於C#的工程化實現及擴充》的出版，博文視點編輯小林對他進行了郵件專訪，現將博文的編輯與王老師的對話整理成文，以饗讀者。

 

博文小林

王翔老師，您好！您即將出版的《設計模式——基於C#的工程化實現及擴充》這本新書，是您結合項目經驗撰寫而成的。市面上已經有一些關於23種設計模式的書，有的已經獲得了市場和讀者的認可，您在文中重新介紹這23種模式時融入了哪些新元素，這些元素對讀者會有哪些協助？

王
翔

設計模式是套思想，我是一名從事開發的人員，有時候會覺得如何更巧妙地結合應用功能完成實現須要多多斟酌。

在我的師傅、同事和領導的協助下，這幾年做了一些.NET的項目，我酷愛C#語言，在使用中發現C#實現一些設計模式的時候有很多特色。

雖然本書很多模式的擴充都很有限，但我希望將其作為一個引子，能夠與喜歡模式& C#語言的朋友有個討論的基礎，不斷完善這部分內容。

從以上寫作目的出發，我主要希望該書能夠對實際工作有以下協助：

1. 打破一些固有的套路。
   
2. 用C#以簡潔、直接的手段解決易於變化的問題。
   
3. 不要僅僅將依賴關係定格在對象體繫上，應更多考慮到應用開發、營運不同生命週期中參與者的工作特點，將依賴拓寬到對象、配置體系、資料存放區和服務體系。
   
4. 面向Web、面向混合資訊體系、面向服務。
   

博文小林

每個程式員都是有獨立性格的個體，這些性格會給學習帶來方法和思路上的影響，您認為程式員學習和使用設計模式來進行開發的時候最須關注的要點是什嗎？

王
翔

同為程式開發人員，我們在對待自己工作的時候總或多或少有些"止於至善"的心結。

代碼、類庫、應用程式框架不僅僅是老闆和專案經理眼中的產品，更是我們敝帚自珍的工作成果，雖然我們可以接受"唯一不變的就是變化本身"，但修改自己的代碼，尤其是因為上遊需求不確定帶來這種壓力的時候，總不是愉快的。

我們要借鑒並應用那些成熟的套路，將變化抽象並集中在幾個點，然後把它們交給營運人員來處理，而我們把時間更多地放在創造性的工作上。

所以，模式是現成的，但實現套路要靠自己。

如果說開發中我們用什麼態度使用模式最重要，我自己的體會有兩點：

1. 敏思（不唯套路，同時不囿於局部）。
   
2. 厲行（如果在適應變化、根據上下文需要應用某些或某個模式的時候，能夠用文法支援的特性、FCL完成，則絕不隨便構造一整套類型系統，而是直達目的）。
   

博文小林

《設計模式——基於C#的工程化實現及擴充》一書中，我們看到了您多年經驗的積累和總結。那麼對於一個設計模式的初學者，您對他（她）們在學習設計模式和本書時有什麼好的建議？在遇到難以捉摸的問題時有什麼比較通用且有效解決辦法？

王
翔

我是個比較循規蹈矩的人，所以我的建議可能收效會慢點。我認為設計模式雖然是思想，但需要對一個物件導向語言有比較紮實的基礎。

以我自己為例。

接觸.NET是因為有個項目我師傅覺得用.NET來實現不錯，然後我去師傅那裡抱佛腳，師傅開啟.NET Framework SDK Documentation，指著語言參考的C#部分和Programming with.NET Framework說："這是你要的"。

不知道是不是有意指點我，記得那段時間他的MSN Personal Message 是"聰明人懂得下笨功夫"。

既然師傅這麼安排，那我就一頭紮進.NET SDK，7個月後.NET項目延期了，不過我把那些文檔全部看完了，C#語言參考還看了兩遍，所有的範例程式碼也都調試過了。

然後看到《設計模式：可複用物件導向軟體的基礎》，第一遍看的時候，經常覺得"哦，這個太Cool，有收穫"，但第二遍看的時候，有很多地方會覺得"這麼麻煩，用C#，一下子就OK了"。

所以，設計模式是思想性的東西，但需要在語言上多做些準備，學習的時候要敢於否定自己以前已經很熟悉的套路，甚至是經典中提出的套路，自己給自己一個不斷突破的目標，經過批評和自我批評之後再看《設計模式：可複用物件導向軟體的基礎》，應該就有更多心得和收穫了。

至於痛點，我師傅也有句話——"重複的力量"，看不清楚就敲擊鍵盤調試它，幾遍之後會突然有一個頓悟的時刻。本書概念上最難的是Visitor模式，前面在Observer和Proxy也有個跳躍式的過程，您也可以用"重複的力量"擊潰它。

博文小林

您在全國海關資訊中心從事過很多大型的開發項目，您日常負責的工作主要是哪些？本書重視設計模式的工程化實現和擴充，這些工程化的內容與您的工作有哪些聯絡？在書中您是如何體現工程化思想的？

王
翔

我的工作職責主要有三個部分：

1. 作為開發部門的進階技術架構師，主要負責行業業務系統的開發。
   
2. 作為資訊安全工作群組的成員，參與公開金鑰項目的實施和擴充。
   
3. 作為最佳化小組的成員，參與行業主要業務系統的最佳化，務求Do more with less。
   

本書涉及的內容基本上都是從這幾年工作經曆中抽象、簡化出來的，雖然書名有"工程化"，但其實更偏重"工程化實施的功能特性"，因為容錯、保密、異常處理、高可用、鎖和並發管理基本上沒有體現在樣本中。

不過本書中也提到了如何透明地加入這些機制，並且還介紹了可以隨插即用的模式，希望您不要錯過。

我工作的行業是一個快速變化的行業，最近幾年每年的增長率都在20%以上，同時又隨著全球化、地區化而快速變化。因為業務上的變化要求，技術上必須做出相應的處理，因此發現《設計模式：可複用物件導向軟體的基礎》後，我就再也沒有放棄過它。

這幾年行業的標準化程度有了質的跨越，外部環境中Web 2.0、SOA、雲端運算和納米計算的概念也在興起之中，所以書中很多地方提到的XML方式，既是順應需要，又是不得已為之。希望其中一些粗淺的方法也能用在別的行業中。

博文小林

在經典的23種設計模式之外，您在書中還擴充了一些架構模式如Web Service模式，介紹這些並不屬於傳統模式的模式，您是出於哪方面的考慮？在深入這些模式之前需要有哪些必要的知識準備？

王
翔

項目需要，估計別人的項目中也已經越來越多地涉及了這些內容。

完成一個項目，不同類型的模式可能要相容並包，"尺有所短，寸有所長"。

我有一點體會，不管什麼類型的模式，哪怕它叫"架構"，都應該有個"作業面"（借鑒地質、能源行業常用的詞），每次經過抽象和簡化，不管什麼模式其實面對的都是一個相對有限的小情境，頭腦中儲存的不是按層次分類的模式，而是一個長長的列表，然後根據上下文選擇合適的，不要受架構層次一定要用所謂的架構模式、類層次一定要用《設計模式：可複用物件導向軟體的基礎》中那些對象關係的羈絆，基於組件化、服務化，我們已經可以較容易地拿捏出這個"作業面"。

至於這些擴充部分，準備知識恐怕還是經典的GOF23和相關領域的開發體會。

另外，比較遺憾，沒能在本書中把資料訪問模式、整合模式、公開金鑰體系中的資訊安全模式、XML設計模式和資料庫設計模式涵蓋進來，如果有幸再版，我希望可以把它們補充進來。