寫作背景：
一直在看關於設計模式的書並不斷的實際工作中努力實踐，同時也看到了播客園上設計模式
團隊文章熱火朝天的研究和討論。心裡非常高興，在國內設計模式的研究和使用還不是很豐富和
完善的今天，這種討論無疑會對每個園中的個體還是播客園整體實體的提公升有著重大的意義，我
非常希望以後想研究.net程式的人只要知道兩個**就能完成工作中90% 的知識查詢，乙個是微
軟的msdn，乙個就是播客園。
第一重：[模式 呀 魔式]
並且手冊上也把這些模式分成了三種型別，這三個型別對我後來理解設計模式又引入了新的
思考方向，它們分別是建立型，結構型和行為型，而上面提到過的那三個模式分別歸屬於這三個
型別：如abstract factory屬於建立型，bridge屬於結構型，而strategy屬於行為型，這時我才有些
開竅，原為這是因為出於在程式設計執行時在從物件的建立，到其中的結構演化到後來的表現行
為模式這幾個部分來進行研究的。真是有些慚愧，因為一開始我覺得這是那四位大師顧弄玄虛呢
。而這時再回到上面所看的那個類似於蜘蛛網或者說是地圖的那個圖上，我才恍然大悟。原來，
設計模式之後的關聯轉換是有著千絲萬縷的聯絡的。其實到後來我看這張圖越看越象是人體的七
經八脈圖，其中的那些箭頭很像是人體血液在人的外界行為模式影響下沿著一定的方法有序流動。
而composite有些象人的大腦，與它身邊有著聯絡深化的模式多達8種。而strategy模式又與建立型
模式中的大部分模式有著單線聯絡。其中的strategy->template method-->factory method
abstract factory恰恰能夠解釋為什麼strategy，abstract factory在結構的右半部有非常相似的**
和**樣式，原來兩者乙個是出於對template method中處法具體實現的步驟[strategy],而別外乙個
卻是出於對templatemethod模式的在建立物件使用方法上的進行了系列化的實現[abstract factory]。
這也再次說明了了解那三種型別對於設計模式理解上的重要性。
這乙個階段我犯的最大錯誤可能就要說是對設計模式所提供的**過於機械性的理解了，
雖說它能讓你一開始很快將一種模式付諸實現，但由於示例**本身沒有專深的業務應用背景，
同時，還有可能會把一些以後開發用不上的**也帶入系統，增加系統的**維護量，另外還會
讓維護人員對系統產生不必要的誤解。本人曾經在1年前的乙個**開發專案中犯了這個錯誤，
最後導致開發的系統核心和未來要進行的開發難度過高而被放棄，最後還是使用最保守的方法完
成了工作才得以解脫。
另外這個階段的程式設計師往往都有很高的熱情，希望能將所學到的模式的知識轉化為生產力，
從而導致在設計中不顧任何條件就使用了某種剛剛學到的模式。也許這對於他本身的知識積累來
說是件好事，但對於公司未必是好事一件，因為任何一種新技術在轉化為生產力時都會存在一定
的風險，如果風險迴避不好，很容易造成丟了夫人又折兵的境地。當專案經理一次又一次去問你
開發進度如何，客戶不斷在摧促你完成不斷變化的需求時，我想再好的出發點最終都只是一種單
相思了。因此，我建議當對一種模式了解的同時，也要清楚自己目前的時間和精力，是否允許我
們去做出相關設計或者改進。另外，對設計模式的應用背景一定要非常清楚，千萬而不要生搬硬
套，因為任何一種設計模式都是以**量換取程式的靈活性和可擴充套件性的，編寫和測試**本身
就是一種時間和精力上的巨大付出，因為一定要預留足夠的時間給自己。
還有乙個程式設計師只是關注設計模式書本上的知識，認為看了懂了就是所謂的精通了，孰不知
設計模式也像英語口語一樣要經常反覆的看了理解，因為模式本身就是從實踐中來的，將來必定
會回到實踐中去，一味紙上談兵，最後只能是一場空。
最後一句話，模式不在於你知道和了解有多少種，一切只以好用，易擴充套件，易維護等軟體工
程上常用的衡理標準為準。一味的只重形式或只為實現模式而使用模式，最終都有可能會像武俠
**中常說的那樣-----「走火入魔」。
未完....
設計模式三重天 之三
寫作背景 一直在看關於設計模式的書並不斷的實際工作中努力實踐，同時也看到了播客園上設計模式 團隊文章熱火朝天的研究和討論。心裡非常高興，在國內設計模式的研究和使用還不是很豐富和 完善的今天，這種討論無疑會對每個園中的個體還是播客園整體實體的提公升有著重大的意義，我 非常希望以後想研究.net程式的人...
UI「三重天」之appium（一）
這樣可以在ios，android和windows測試套件之間重用 我們無論在做什麼測試，首先要考慮的便是該工具 框架 是否真的適合自己的業務，自己的需求 顯然跨平台的優點是首選，和之前的jmeter是一樣的。我們不能被工具 框架 限制。客戶端 伺服器架構 會話 自動化始終在會話的上下文中執行。客戶端...
看待設計需求的三重境界
佛家觀世有三重境界 第一重境界是 看山是山，看水是水 第二重境界是 看山不是山，看水不是水 第三重境界是 看山還是山，看水還是水 同樣，在產品需求分析的過程中，也存在三重境界。需求分析的三重境界 在網際網路產品的需求分析過程中，互動設計師觀需求的三重境界。即 第一重 觀需求是需求。第二重 觀需求不僅...