Design&Pattern團隊《設計模式在軟體開發的應用》精華版

在此對team的第一次討論做一些概括。當然，蟈蟈的文章更加原汁原味，各位如果有時間的話可以去看看。

在下面的文章中，大部分論點屬於team，不是我個人觀點。

 

大家對設計模式的認識是怎樣的

vcfly.net  設計模式就是一種思想，但思想的基礎是要有一定的實踐經驗

wayfarer   我認為在應用設計模式上，有兩種方式

              從傳統的軟體開發出發，對體繫結構設計的時候，如果熟悉設計模式，那麼設計的軟體在擴充性和

              健壯性，都比較好

              但如果從TDD的角度出發，設計模式主要還是在重構中體現

蟈蟈       其實應該是在設計模型的時候考慮模式，具體的模式有了，代碼也就出來了 而不拿到模式去套代 

             碼對嗎 

dudu       模式我覺得可以理解為軟體設計的一個理論，學好理論很重要，但更重要的是如何運用理論，就像

           懂得了孫子兵法，不一定你就能打勝仗

           我覺得模式的最高境界就是你在編程中不知不覺地使用模式去解決問題

單一談模式的意義不大，在重構中應用模式，是使用模式的一種常見手段，於是乎大家的觀點自然而然就開始

發散，談到了重構，談到了TDD（測試驅動設計） pairwork xp

重構

dudu       我想我們使用模組是為瞭解決重複代碼的問題，我們在編碼時應該更多地考慮如何避免重複代碼，

           而不是採用哪種模式 

Zealot     我自己的原則是如果copy code三次以上，我就會重構它 

vcfly.net  一個很突出的問題是，系統的功能越來越複雜，這就需要考重用和重構

vcfly.net  我以前改過一個5000行的程式，代碼我給降到了1800行，伸縮性擴充性全上去了，而且功能也多了

           很多，但是執行速度卻降成了50%   

wayfarer   我在讀fowler的重構時，就覺得他寫的步驟太繁瑣，但後來覺得，這種小心謹慎是值得的  

idior      對啊，他是再沒有測試代碼得情況下做得  沒有tdd，重構是很危險和麻煩的

Samuel     設計很重要，但是千萬不要過度！

小陸       開始設計的時候，用最簡單的方式實現。隨著需求的複雜，或者發覺出更多的需求，這時候就不可

           避免的重構，首先整理現有的功能，這時候可能就要應用各種複雜的模式，等到重構就緒，再添加

           新的功能。

dudu       小陸，這是典型的XP思想,

蟈蟈       其實TDD也是這樣的，先寫測試後來代碼，保證所以的代碼是因為有測試才出的 也就是有需求才會

           有測試代碼，這樣就沒有過度了，所以做的都是現在最需要的

pairwork & 客戶

idior      有個問題哪個公司有用pairwork

Samuel     不相信中國的公司會用pairwork

dudu       支援結對程式設計 

umlchina   沒有試過結隊編程，聽起來很有意思

小陸       從來沒有嘗試過真正的xp，試過一次結對程式設計，發現效果很不好，就停止了。有人有成功的經驗嗎

          ？失敗的教訓也行啊

wayfarer   國內的客戶水平還達不到XP的要求

Samuel     非常反對wayfarer 客戶永遠是對的  客戶不懂的 需要你去引導

vcfly.net  反對Samuel

idior      我也對國內客戶沒信心 

Zealot     不要抱怨或期待客戶的水平如何如何，客戶要完成自己的需求，又不想多花錢，這是很自然的。

wayfarer   希望關於結對程式設計和客戶交流等問題，留到下一個主題來

常用模式

蟈蟈       大家經常用到的模式有哪些呢

蟈蟈       singleton，factory，模板，這些都是模式中經典的，但是相對比較容易的

wayfarer   不要盲目追求複雜的模式，往往會造成過度設計

RoyDeng    Composit 在有樹狀結構的場合應用。非常普遍

umlchina   facade比較好用尤其是對付一大堆雜亂的代碼的時候 

wayfarer   其實Template模式，我相信很多人都用過 

idior      強烈推薦bridge strategic state 他們是Favor composition over inheritance的體現 

蟈蟈       其實如果拿模式到一個系統中去套，我相信所有模式都用的上的 

dudu       我現在在編程中也不刻意去考慮採用哪種模式 

模式與架構

jeseeqing  我覺得架構是建立在模式這上的

Samuel     架構需要悟，和patten不是一個層面，模式接近語言層面

RoyDeng    架構？我倒覺得是用模式最多的地方

Samuel     to RoyDeng: 實際上在設計架構時，並不會考慮模式   設計架構或者平台，主要的是通用性、延 

         展性和功能

RoyDeng    你看看.NET的FrameWork

Samuel     當決定了你需要的東西，用模式只是水到渠成 不用亦可  

模式的實際應用

RoyDeng       我覺得越是面向商業，我們所說的模式就用的越少

vcfly.net     是的，因為他要考慮商業風險和代價

wayfarer      關鍵是，我們是做項目，還是做產品

vcfly.net     我給一些公司寫過軟體，他們只考慮功能的實現，基本就不考慮後期的維護，只要拿到錢了， 

            他們就不管了，所以你和他們說模式，全是廢話 

wayfarer      vcfly，你當然不能給客戶說模式了 你只能說你的產品效能、功能，所需的時間，價格，模式 

            是協助你，在設計中提高產品的效能，功能和未來的擴充

idior         有公司面試要求模式的嗎？不是說面試者個人

jeseeqing     有,我以前的公司就面試過  

wayfarer      我以前公司就要求 成都的一家小公司，凱威斯特

模式的作用

wayfarer      我想問大家：設計模式在項目開發中對你們的協助是怎樣的 

蟈蟈          我覺得最大的好處就是省寫很多代碼

idior         維護性和可擴充性 適應未來的變化    理解oo對模式也就理解的差不多了，同樣學習模式可以

             協助你理解oo

wayfarer      其實，通過我對設計模式的學習，確實加深了我對OO的理解

春魚          我覺得模式還有利於溝通

du            模式是很多人經驗的總結，避免我們少走許多彎路，你可以不用模式，但你必須真正完整模式

wayfarer      我始終將模式看作兩個層面：一是思想，他能協助我們理清設計的思想；一個就是工具，他能 

              協助我們有效地設計  不能為了模式而模式

dudu          建議大家床頭放一本設計模式的書，沒事就看看 

idior        順便說說模式的好處：

             可以重用已有的好的設計，可以提供一套供程式員交流的語言

             模式可以讓你站在更高的角度去看待問題，看待設計的過程，更加體會OO的思想，而不是過早的

            捲入編碼的細節。  

             看待問題應該從大處著眼，而不是關注於實現的細節。模式可以提升你看問題的抽象程度。這才

            是模式最大的益處。  

             模式是經過考驗的思想，比那些突然的想法更可靠，更具有擴充性。

             通過學習模式將對OO的思想有更深的體會。

這是我對討論的摘要。大家可以在此基礎上繼續評論。這樣聊天就可以繼續啦 :） 希望大家響應啊，那樣在下

次開會前就能整理出一個更完善的模式專題報告. 不然一個小時的時間實在太少啦，通過這種方式可以延長討

論。

我突然想到一個方式，就是在team討論的時候，大家引出一些觀點，並給出一些爭論，然後通過評論的形式，

將討論不斷完善。最後再加以總結。大家覺得怎麼樣？