其他

發表了兩篇文章，沒有發到首頁上，沒想到訪問量這麼低，汗啊..........不過既然要寫還是寫完吧，看來Dota的隊伍不夠大呃。當作我自己總結了這篇是簡單工廠，實際上簡單工廠不是Gof的23個設計模式一員，但是還是有必要說說滴，先來個UML圖吧： 設計模式的目標是解耦，把變化的部分各類來，本次Dota的例子是選擇遊戲類型的命令（-ap，-ar，-rd等等）。首先我們有命令對象，如下所示： CodeCode highlighting produced by Actipro

Factory 方法，特徵就是“方法”上，由子類實現父類的抽象方法，把建立產品的責任轉移到子類中。先上UML圖：還是以Dota遊戲為例，我們的工廠是Dota中建立模型的工廠，而產品則是不同的模型。首先我們要明確需求，Dota中需要建立N中Model,包括英雄、野怪、樹木等那麼我們的產品類如下：Code highlighting produced by Actipro CodeHighlighter

 抽象原廠模式即Factory 方法模式的集合。Factory 方法得到一種產品，而抽象原廠模式得到一系列產品。同樣先來UML來個總體認識：一、抽象工廠類抽象工廠是GameFactory，它生產兩種產品（英雄，建築。當然包括更多，本文只給出兩種）。   

策略模式，是演算法族的集合，將演算法抽象出介面，並根據介面實現各種演算法。在使用演算法的具體類中設定相應的演算法，為什麼有策略模式的誕生，建議大家看下Headfirst，裡邊的介紹是相當的詳細，看完後保證有茅塞頓開的感覺。UML圖：策略模式中講究的是組合，演算法族的建立。本文的演算法族是英雄的行動IAction介面。Dota中的英雄有走著的，有飛行的，有爬行的。分別寫行走類，飛行類，爬行類繼承IAction介面。IAction可以在建構函式中設定，也可以在用戶端調用時動態設定，有著很靈活的狀態。

IHttphandler是什麼，表面上看他是一個介面，實際上他可以把用戶端提交的請求進行處理後返回給用戶端。IHttphandler介面包括IsReusable屬性和ProcessRequest方法，IsReusable屬性是指是否可以重用，ProcessRequest方法用來處理用戶端的請求。群裡有人提出了Url重寫的需求，閑來無事便幫忙實現了下。那位兄弟的需求如下：輸入如下格式http://localhost:2868/cgi/redirectform?uid=pxl&pwd=123

IHttphandler原理已經在“IHttphandler之Url重寫”一文中講述，有不理解的同學可以參看該文章。本文是對網站的圖片進行浮水印處理。原理相同，關鍵在web.config的配置，以及GDI+操作。首先對web.config配置如下：<httpHandlers>      <add verb="*" path="*.jpg" type="MyHttpHandler.WaterMarkHandler,MyHttpHandler"/>   

單件模式，單件意味著唯一，我們建立的類的執行個體是唯一的。唯一的處理印表機，訊息佇列，註冊表等等.......UML圖：單件模式看來簡單，其實不然。包括什麼雙重加鎖（多線程要求），延遲執行個體化等等，具體在TerryLee的blog上有詳細的描述，本文不再羅嗦。單件模式沒有公開的建構函式，要實現對象的執行個體化只能依靠靜態GetInstance方法。在GetInstance方法中判斷對象是否存在，存在則返回該對象，不存在就執行個體化一個對象返回。Dota中時間是唯一的，以下的例子是對白天黑夜的控

代理模式分為好多中，什麼透明代理啦，遠程代理啦，安全代理啦，本文介紹的是最基本的代理。UML圖：真正的對象和代理對象均繼承相同的介面，執行個體化代理對象時將真實對象傳入，當操作代理對象時感覺像是在操作真正對象一樣。像是代理對象把真正的對象封裝後再在用戶端處理。  

繼承的優缺點 優點 新的實現很容易，因為大部分是繼承而來的 很容易修改和擴充已有的實現 缺點 打破了封裝，因為基類向子類暴露了實現細節 白盒重用，因為基類的內部細節通常對子類是可見的 當父類的實現改變時可能要相應的對子類做出改變 不能在運行時改變由父類繼承來的實現 由此可見，組合比繼承具有更大的靈活性和更穩定的結構，一般情況下應該優先考慮組合。只 有當下列條件滿足時才考慮使用繼承： 子類是一種特殊的類型，而不只是父類的一個角色 子類的執行個體不需要變成另一個類的對象

實體查詢 例子1： Hql代碼 String hql=”from User user ”; 　　   List list=session.CreateQuery(hql).list();   String hql=”from User user ”; 　　List list=session.CreateQuery(hql).list(); 因為HQL語句與標準SQL語句相似，所以我們也可以在HQL語句中使用where字句，並且可以在where字句中使用各種運算式，比較操作符以及使用“and”,”

什麼是SQL注入式攻擊？ 所謂SQL注入式攻擊，就是攻擊者把SQL命令插入到Web表單的輸入欄位或頁面請求的查詢字串，欺騙伺服器執行惡意的SQL命令。在某些表單中，使用者輸入的內容直接用來構造（或者影響）動態SQL命令，或作為預存程序的輸入參數，這類表單特別容易受到SQL注入式攻擊。常見的SQL注入式攻擊過程類如： ⑴ 某個ASP.NET Web應用有一個登入頁面，這個登入頁面控制著使用者是否有權訪問應用，它要求使用者輸入一個名稱和密碼。 ⑵

備忘錄模式，最直接的就是記錄遊戲進度了，如果有個18關的遊戲不能記錄遊戲進度，每次都必須從第一關開始玩，那你是不是要放棄遊戲了，我肯定會的，嘿嘿。在C#中序列化使我們能夠更方便的完成備忘錄模式，UML圖先給大家一個概念：具體代碼見完整代碼。測試代碼：            DotaPatternLibrary.Memento.Game game = new DotaPatternLibrary.Memento.Game();            game.GameLevel = 1;     

觀察者在生活中最顯而易見的例子就是報紙訂閱了，此時報紙內容是主體，而每個花錢訂閱的家庭就都是觀察者。當你訂閱時報紙出版商會將報紙按時發到你的訂報箱，當你停止訂閱是你的訂報箱將會是空的，當然你隨時可以訂閱或取消訂閱。UML圖：觀察者模式對主題資訊的處理方式分兩種，“推模式”和“拉模式”。framework中最明顯的觀察者模式要算是事件了，你可以使用“+=”來添加觀察者，也可以用“-=”來取消觀察者，而時間的兩個參數“sender”和“eventarg”要算是推模式和拉模式的結合了。比如btnXXX

多線程，一個古老的話題，今天我來聊下最基本的線程，UI線程和後台線程。在後台線程中直接操作UI控制項會出現異常(線程間操作無效：從不是建立控制項“XX”的線程訪問它)。怎麼解決這個問題那？關鍵點在代理和InvokeRequired屬性，Winform的UI（視窗）代碼如下：Code highlighting produced by Actipro CodeHighlighter

      熟悉這張圖嗎？如果你是DOTA玩家，那麼開始我們的模式之旅吧。     如果不是，很遺憾，你需要在魔獸爭霸RPG地圖中娛樂一周后再來看看。     本人語文自幼不才，還請各位海涵。     最近和部落格園一個QQ群的網友無意提起了Dota（就是那個成天JJ掛在嘴邊的蜘蛛同學），發現其中包含著一些設計模式隨口說了幾句，誇下海口要寫點東東，為了不成為傳說中的TJ，決定開始寫起.........     本人剛接觸模式不久，歡迎高手賜教。其實寫這個系列的最重要原因是老婆可以讓我每天Dota

Winform控制項分為使用者控制項和自訂控制項，使用者控制項比較簡單，本文討論的是自訂控制項。MS控制項，無論是Winform控制項還是Webform控制項，無論是使用者控制項還是自訂控制項，都有著相同的設計思想。1）對於自訂控制項來說：Winform控制項的UI顯示是靠OnPrint方法，Webform控制項的UI顯示是靠RenderXXXX方法。2）對於自訂控制項和使用者控制項來說：Winfrom控制項和Webform控制項的屬性在UI設計中起到了至關重要的作用。在設計檢視中都可以設定屬性

責任鏈，看到名字大概就能瞭解到這個模式的含義了，就是有N個責任，組成一條責任鏈，進行流水線作業。舉個生活中的例子，比如你要請假，請假是時間比較長（十個月），你去找Leader組長，組長一看假條迷惑的說，你要去生孩子嗎？這個你得去問專案經理。然後你又轉戰專案經理那裡，專案經理看了說，你是十月請假看國慶典禮那，還是請十個月假回家休養。你肯定得告訴專案經理你要請十個月假。專案經理皺皺眉頭說，這個我說了沒用，你還是去問老總吧。當你把假條放到老總面前的時候，老總說了句：回去吧，你不用來了。到此責任鏈執行完

面板模式，不知道你是否會碰到這樣的情境，公司要開會了，由你負責布置會場，你需要做的工作有：1.把窗帘拉下來。2.擺好椅子。3.降下投影幕布。4.開啟投影儀。5...............太煩了，有時你甚至少做了一樣，別怕，如果有了面板模式就可以高枕無憂了。簡單的說，面板模式就是把1～5條甚至更多的操作抽象為一個操作，那就是------------開會布置在本例中，面板模式就是把遊戲初始化的操作合并為一個操作，Game類中的GameStart。此模式比較好理解，具體請see完整代碼喲。測試代碼：

命令模式看起來好像簡單些，實際還是十分複雜的。代碼比較簡單，所有的Command只要繼承了ICommand介面即可。    public interface ICommand    {        object Execute();    }具體的Command類見完整代碼。Command對象在建構函式中定義操作的對象，Execute方法調用建構函式中定義的對象。本樣本缺少了Undo的實現，只要在執行命令時把命令記錄下來，執行Undo時進行反操作即可。UML圖：測試代碼：           

適配器，顧名思義是用來適配介面的，就拿我們常用的筆記本來說吧。大家都知道我們的筆記本在使用時都通過適配器串連電源，那是因為筆記本需要的電壓和插座提供的電壓不同，需要把插座提供的電壓適配為筆記本可以接受的電壓。廢話不多說，UML圖是必上的：適配器分為對象適配器和類適配器，由於類適配器需要用到多繼承所以與C#無緣了，所以我們來研究下對象適配器。本文中將要把野怪適配為英雄，假如說現在有個英雄的介面，什麼呐？當然是說話了，介面如下所示：