其他

最近收集到很多資料，關於一些不在GOF中的設計模式，於是有了一種要把這些share出來的想法，列表如下：1.不變模式2.過濾器3.唯讀介面4.動態連結5.緩衝管理6.小語言7.Null 物件8.雜湊配接器物件9.單線程執行10.靜態鎖定順序11.鎖對象12.受保護的掛起13.阻行14.調度器15.讀/鎖寫入模式16.生產者－消費者17.雙緩衝18.非同步處理19.Future模式以上參考於《Visual Basic設計模式》一書，我會將其轉換成C#代碼。本文算是前言了。

本系列目錄程式碼範例下載不變模式，這是一個非常基礎的模式。從對象的健壯性來思考：這些對象共用相同對象的引用，為此，在物件建構好之後，不允許改變共用對象的內容。這就是不變模式，在程式中使用它的地方越合適，程式將越健壯，可維護性就越強。從並發的角度來思考：不變模式解決的是如何處理共用對象的問題。當多個對象使用或修改同一個類執行個體——也就是共用對象的時候，往往會有同步問題；而在多線程非同步呼叫的情況下，則更難以控制這個共用對象的狀態。一種解決辦法是，使用了Lock的機制來鎖住對象，強制進行同步，但是

第2章 無名特質（The quality without a name）      存在著一個極為重要的特質，它是人、城市、建築或荒野的生命與精神的根本準則。這種特質客觀明確，但卻無法命名。      這讓我想起了獨孤求敗之“手中無劍，心中有劍”，何其的相似。看著郵差機械式地往信箱裡投郵件，看著田間老農“空中接力”傳運西瓜，我也留意到了這種特質，但確實不好命名，因為一旦執行個體化，就會限定死了若干條件，而沒有“生氣”了。      WOW，終於發現抽象類別存在的價值了。     

 楔子話說，500年前的一個白天，伸手不見五指——不是沙塵暴，也不是日食，而是一個腦門上刻著dudu四個字的鳥人，揮舞著一對熾天之翼在空中遊走。忽然，隨著一聲慘叫，那個鳥人與翅膀相脫離，鳥人做自由落體運動墜入S城，生死不明；而那對翅膀，則一點點地消失於陽光與空氣中，直至最後一片殘體沉入B城的萬丈深淵之中。於是，人世間為了尋找這對隱性的翅膀，掀起了一場血雨腥風。 一  黑風雙煞Anders

一提到這個模式就會想到“擊鼓傳花”這個遊戲。這個模式的核心主要是Handler抽象類別，幾個設計要點：1.它要保持對自身的一個引用，就是next欄位以及相應屬性2.DoHandler()方法是一個遞迴遍曆，直到處理完這個請求    傳入的參數字串s是等待處理的請求，當然，這個參數可以是任意類3.HandlerRequest()方法要抽象出來，    傳入的參數要與DoHandler()方法的參數保持一致    一定要返回bool型，以表示是否處理了這個請求；    public abstract

無心之心，道之所存（To you, mind of no mind, in whom the timeless way was born.）   

剛寫完項目的一個UT，下面是在涉及UT時的一些新得，和以往的UT不太一樣哦：1.Model中不要有方法，提升到ViewModel層級。2.MessageBox封裝成ShowMessage(string

GOF的定義：給定一個語言，定義它的文法的一種表示，並定義一個解譯器，這個解譯器使用該表示來解釋語言中的句子。這個模式很少用到，我看過一個機器人指令的實現，使用了該模式。兩個子類的實現，TernimalExpression類是具體做事情的類；NonternimalExpression類是一個容器，它的interpret方法，負責遍曆其內部的所有TernimalExpression對象：Code highlighting produced by Actipro CodeHighlighter

    研讀《建築的用恒之道》一書，讓我永遠記住了Christopher Alexander（簡稱C.亞曆山大）和俄勒岡大學。很奇怪為什麼很多人都認為他已經作古了，大概越是權威距離我們就越遙遠，不過，大師確實已經進入了古稀之年。讓我們八卦一下他的個人資訊。     這確實是一個比較低調的人，以至於隔行如隔山的我，對他進行人肉時並不是很容易。幾經周折，我還是找到了詳細介紹他個人資訊的網站：http://www.patternlanguage.com/leveltwo/ca.htm。   

不小心翻到了部落格園精華集事件的文章集。唉，一年前居然在沒日沒夜地忙這個！文章看過很多遍了，包括老大的，我的，老怪的，DX的，沒什麼好說的。評論很有意思。有善意的，有出主意的（當然有一些是餿主意），還有就是那些煽風點火唯恐天下不亂的，現在想想還真好笑。第一本馬上就要出版了，不知道和我想象的是否有出入。很忐忑，有一點失誤就會遺臭萬年了，不過也只能寄希望於出版社了。想想我也滿傻的，為了別人的利益去和出版社鬧翻。於是又開啟MSN的曆史紀錄。一年前編委會MSN群天天有說有笑的，不像如今大家各忙各的一盤散

狀態模式是把各種狀態封裝成不同的類。關於Context類的實現，不太同於Strategy，雖然原理是一樣的：    public class Context    {        private State stateA, stateB, state;        public Context()        {            stateA = new StateA();            stateB = new StateB();        }        publi

     一天到晚show他的許可權系統，水啊水，沒有一點技術內涵，部落格排名卻扶搖直上。     不過，習慣了看小丑的表演，調劑一下也不錯。就算進了前10，也是最有趣的反例，至少證明了部落格園菜鳥還是很多。     一句話，他不懂社區，他把社區當作了賺錢的工具，這種人難道不是小丑嗎？     部落格園畢竟是技術匯聚之地，偶爾yy一下能緩解神經開闊思路，但每天都把廣告、牢騷和水文堵在首頁就不行了。屁大個人，屁大個公司，屁大點事兒，整天念經似的嘮叨不休，搞得大家都很浮躁，靜不下心來做技術。    

Observer模式的迷人處在於它實現了.NET事件機制，這使得它在OO設計中大放光彩。定義：觀察者模式定義了一種一對多的依賴關係，讓多個觀察者Observer對象同時監聽某一個主題對象Subject。這個主題對象在狀態上發生變化時，會通知所有觀察者對象，使它們能夠自動更新自己。逐個分析：1.Subject是一個集合類，負責將所有的Observer註冊到弱集合arr中，這個由Attach()方法完成——我們同時會提供Detach()方法   

    在建立一個新的工作流程時，需要做出一項重要的抉擇：我們要建立的工作流程究竟是一個順序工作流程，還是一個狀態機器工作流程？WF提供了兩種“即開即用的”（out of the box）工作流程執行類型。為了回答這個問題，我們不得不決定誰在受控。    順序工作流程是一種預知的工作流程。執行路徑可能是分支、迴圈、或等待一個外來事件的發生，但是最終順序工作流程將會使用活動、條件和我們在前面章節所提供的必不可少的匹配規則。工作流程在進程中受控。   

【旁白】有一座武林，它的名字叫部落格園。有無數程式員，隱匿其中，晝伏夜出。其中，流傳著一本武林秘笈，記載著眾多高手的絕世武功，擁有它意味著稱霸整個部落格園。於是，三教九流、奇人異士為了這本書而PK，大打出手，甚至掀起了一場腥風血雨。終於，這場曠日持久的爭奪戰只剩下了兩個人。【注意，旁白說到武林秘笈時，一本書旋轉出場，書的正面照】【注意，旁白說到三教九流時，顯示圖片，編委會個人照片逐個彈出在一個屏上】【注意，旁白說到大打出手時，顯示圖片2】【注意，旁白說到腥風血雨時，顯示圖片3——需要拍一張很多人

當不再使用for迴圈，替代以foreach/GetEnumerator，當從if條件/switch分支得到的不再是string，而是一個工廠對象，                        

http://book.csdn.net/bookfiles/103/1001038134.shtml設計模式源自建築學和人類學http://blog.csdn.net/sanlongcai/archive/2008/01/02/2010677.aspx談談《建築的永恒之道》中的內容安排和整體思路http://blog.run2me.com/johnxu/archive/2008/11/08/33920.aspx從我的感受裡，讀此書最大的收益不是關於建築，而是更大範圍的藝術、設計，還有人生之道。

這個模式是對模板方法的簡單封裝，可以看到，只是多了一個Context類這個封裝器。以上UML圖的代碼很好實現，關鍵是Client如何使用Context類：            Strategy s = new ConcreteStrategyA();            Context context = new Context();            context.Strategy = s;            context.ContextInterface();用戶端必須知道所

　　原文地址：《不懂介面、反射、委託、設計模式足足寫了5年的代碼 -- 寫給初學者(談美女產生器不談代碼產生器) 》　　吉日有三篇文章，是我最深惡痛絕的，堪稱誤導新人之三部曲：1.白話講反射技術 --- 適合初學者入門引導2.白話講山寨SOA，少一些迷惑、多一些理解，你的程式架構SOA了嗎？3.不懂介面、反射、委託、設計模式足足寫了5年的代碼 --

模板方法很簡單，只要有抽象類別的地方，都可以看到這個模式：就是在父類中的非抽象方法中調用抽象方法。基於委託的模板方法：從而具體實現方法可以不依賴於抽象類別，達到解耦的目的幾點注意：    1.delegate聲明在模板類中    2.在類DoCompA和DoCompB中定義與委託相同的方法    3.在Main()中組裝委託鏈，調用tm.DoComp()意味著這是一個模板方法(非抽象中方法調用抽象方法)    public class TemplateMethod    {        pub