|
|
這幾日，在閱讀GoF之一的John Vlissides著作《設計模式思考》，在James O. Coplien為本書所撰寫的序中，摘引了Richard Helm的一封郵件：
GoF的設計模式只解決了微觀架構（micro-architecture）。你仍然必須把宏觀架構（marco-architecture）設計好：分層、分布、功能隔離……。而且就像Cope說的，你仍然必須把納米架構（nano-architecture）設計好：封裝、liskov……。
我很贊成這種根據設計粒度來劃分架構的方式。從嚴格意義上講，軟件設計也可看做是架構的一部分。從marco-architecture到micro-architecture，再到nano-architecture，是一種設計粒度的自上而下。但在架構過程中，我們并非一定要從宏觀到微觀，再到更為具體的細節，這些架構其實是平等的。這幾種粒度的架構，似乎存在某些玄奧的原則與設計精神，貫穿其中。我以為，如果能把握它們之間的脈絡，甚至通過某種方式將它們串聯起來，形成一種有機結合或者說渾然一體的架構，對于我們的架構與設計而言，無疑會帶來極大的幫助。
最近一年來，我一直在思考隱藏在設計背后的基本思想與原則。因為在紛繁復雜的模式中，我們很容易迷失自己，要么患上模式病，要么在選擇模式方面變得無可適從，或者就干脆鄙視模式，按照自己的一套方法野蠻施工。不幸的是，這種野蠻施工在有時候確乎能取得不錯的效果。然而，這無疑落入了一種類似“按巧合編程”的反模式陷阱中，我將其稱之為“按巧合設計”，即在項目或產品設計過程中，因為偶然原因，設計取得成功，從而給設計者帶來錯覺，以為尋覓到了某種“放之四海皆準”的終南捷徑。
我對設計的思考總結而言，包括七個方面，即“重用、擴展、變化、分離、簡約、一致、間接”。我在多次會議上也闡述和分享了我的這些想法（當然，這些想法絕非我的獨創，有很多其實本身就是業界公認的原則，我不過是期望能夠融為一體地來闡述架構與設計這一命題。）然而，囿于自身經驗與能力，我還未能將其總結得更好。我對設計模式（即所謂微觀架構）的理解是有幾分自信的，對于OO的基本原則（即所謂納米架構），也可以說是深諳于心，但對宏觀架構的把握，還欠缺幾分火候。我始終感覺我的總結有一些散，我追求的設計原則，應該像散文的精神那般，能夠做到“形散而神不散”，而現在對設計的理解正好缺乏某種能夠符合類似天體運行規律的鏈條所在。Richard Helm對架構的敘述，為我打開了一扇窗戶。
此外，通過我這幾個月負責的產品研發，我對UML的理解也更近了一層。我越來越覺得UML對架構和設計的幫助。正如Craig Larman的那本名著《Applying UML and Patterns》，UML與模式可以結合得更緊密一些。UML的重要性不言而喻，如果有人對其產生輕視，乃至于鄙視，歸根結底，一定是對UML進行了誤用或者濫用。UML是工具，但它不同于普通的工具，它能夠啟發我們的設計。例如用例圖可以幫助我們識辨角色與場景，還可以幫助我們找到能夠重用的元素。組件圖無疑屬于宏觀架構的范疇，它幫助我們體會封裝與松散耦合，還能夠幫助我們定義服務。我不認為從一開始，就只能利用組件圖來劃分模塊，畢竟在很多時候，我們很難完全對模塊進行分解。但如果能夠合理地利用組件圖，對模塊的劃分無疑會變得輕松許多。在微觀架構的層面，我特別喜歡時序圖（sequence diagram），在我心中，它的重要性甚至勝過測試驅動開發。結合用例圖，它能夠幫助我們找到對象協作的順序與方式，幫助我們找到抽象以及接口，當然還包括對象的職責。我們還可以適當地結合ICONIX方法，并結合原型，來幫助我們對用例場景的理解，并最后找到必須、應該且恰如其分地需要參與到這一場景中的業務對象。
從架構的角度來看，我們需要將自上而下與自下而上兩種方式進行結合。此外，我們必須遵循所有層級架構都應遵循的原則，例如高內聚、松耦合以及關注點分離。我在思考，這些基本原則，似乎正是我要尋找的穿起納米架構、微觀架構和宏觀架構的鏈條呢？如果是，我們該怎樣運用它們。畢竟，對于大多數設計者而言，這些原則都太空泛，太抽象，以至于落入玄奧的“道”中無可自拔。架構與設計自然有其玄妙之處，有其不可言傳之處，但如果一味地故弄玄虛，并不利于設計者的提高。因此，對我而言，我希望能夠提供大量的案例，來佐證這些原則；更重要的不是佐證，而是指引，以好的例子，甚至可以稱為典范的例子，展現這些精妙的原則，使得我們的開發人員都能夠看懂，都能夠理解設計的妙處。這是我努力期望做到的。
若要做到這一點，我必須還要提高自己的架構與設計水平。但我以為，我幾乎要尋覓到登堂入室的入口所在了。我期待自己能早一天找到它！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
