其他

前面一篇，我們寫了一個代理類，可以實現一些功能，但作為動態代理類的原型，還是有問題的。我們來改進一下原來的類，如下：    /// <summary>    /// 代理類，從AClass繼承.這是必須的，否則AClass能用的地方， ProxyAClass1卻沒法用.這裡的改進主要是將需要切入的委託，採用構造參數傳遞進去，有利於動態構造執行個體。    /// </summary>    public class ProxyAClass1 : AClass    {  

前些天跟一個人聊起我自己的一個系統，我說是delphi做的，他說那太落後了，然後說了一堆，我只能汗。雖然我現在主要在dotnet平台上做事情，但我對delphi還是有感情的，畢竟用了那麼多年，而且至今我覺得從開發速度上來說，至少在案頭系統開發方面，無人能及。Delphi至少有幾個地方還是非常的經典：1、UI組織，Delphi的Form是可以繼承的，這個東東非常有用，在提高開發速度方面簡直就一個神器。2、BDE：這個東東的Query和TUpdateSQL結合，再加上datasource可以跨for

如果一個類（CA）的方法存在不同的演算法（F），而這些演算法使用者都可能用到，那麼就可以將這種演算法獨立出來自我演變，既提供一個演算法的抽象介面，再定義具體的演算法類，而CA保持對演算法的一個引用，CA中的方法不直接實現演算法，而是調用使用者所選的演算法類中的演算法來實現，這就是策略模式。也既定義一系列的演算法,把它們一個個封裝起來, 並且使它們可相互替換。本模式使得演算法可獨立於使用它的客戶而變化。  *  *                   |￣￣￣￣￣￣￣￣￣|            

1)測試資料準備：//這是我學習treeview綁定時用的，也隨帶給不是很會用treeview綁定的網友們一個例子.A)層級類，樹形結構.public class Folder    {        public ObservableCollection<Folder> Children { get; set; }        public string A { get; set; }        public string B { get; set; }   

裝飾的含義就是在原有的物件上增加飾品，使得物件能呈現出不同的特徵。當然在類設計中，採用裝飾模式，是用來為類增加新的特徵和行為。結構如下：    *     *                   |￣￣￣￣￣￣￣￣￣|                                  *                   |     Component           |<--------------------------------------------------------

    什麼事情都有良性迴圈和惡性迴圈，工作也是一樣。程式員這份工作更是如此，特別是你如果和我一樣未來只想走P的道路。    昨天晚上老大給我發了一個郵件，關於規劃部門最近在規劃阿軟的未來技術發展，希望能夠提供關於分散式運算的一些想法和Feature，最近也接觸和實踐了一點，就寫了一點自己的想法。老大很驚訝我那麼快就回了郵件，其實在我看來還是和我讀書的時候老師常說的，“機會總是給有準備的人”，就算中五百萬也需要有承受的心理。   

Author：放翁（文初） Email：fangweng@taobao.com Blog：http://blog.csdn.net/cenwenchu79 其實想說這句話很久了,和很多同事接觸,有時候或多或少的都會發現大家會陷入在自己的一畝三分地裡面.         主要表現得癥狀1.       PD的需求就是目標，踏實的實現，不懂的就猜。2.      

本來打算寫得細些，但最近要換工作，所以比較忙點，而且也覺得沒必要寫那麼多虛的東西，因此這裡不再按照提綱進行，而是從代碼入手，看清Silverlight的互動機制.相依性屬性和附加屬性的基本類都是一樣的，但相依性屬性和附加屬性的用途還是有區別的，相依性屬性更多的是屬性，而附加屬性更多的是擴充，有點類似於類的擴充方法，附加屬性非常重要，很多互動的實現其實都是利用這個特性來實現的，附加屬性為你對現有UI元素進行互動注入提供了切入點。從某種意義上來講，這也是AOP編程的一個典範。相依性屬性的類比可以參見

下面是依賴對像類的實現：（注，這裡涉及到INotifyPropertyChanged介面，大家可以參考MSDN文檔瞭解). /// <summary>    /// 依賴對像，主要提供屬性值和屬性綁定的管理。    /// </summary>    public class MyDependencyObject    {        private IDictionary<MyDependencyProperty, object> _dict = new

今天比較深入的接觸了一下VS的MVC開發，有點感觸，所以寫點感言。因為接觸不是很久，研究不夠深入，寫這些主要是測試一下自己的技術敏感度，如果下次發現自己寫得不對，其實也是一種提高，所以大家看的時候，就當娛樂吧。我們首先來看看MVC和WebForm:1）首先MVC和webForm還是屬於比較典型的BS程式，所以本質上它們沒什麼區別，理由如下：      A）構成：Web的構成是Aspx+CS檔案，MVC是M+ASPX+Controller(CS),其實M相對獨立，傳統的Aspnet也可以擁有這層，

下面我們來看看IOC和AOP的一些優劣：IOC：優勢：1）可以解耦一些邏輯關係，使得這種關係更加鬆散，而且可以在不重新編譯器的情況下通過配置資訊的更改達到更改程式邏輯的目的；2）可以大量減少一些中間（比如典型的建立邏輯）類；3）帶來了很大的靈活性和可擴充性。劣勢：1）只適合邏輯比較簡單，而且形式比較統一，量比較大的地方，對於複雜的邏輯使用設定檔完成，反而會增加系統的複雜度和難度；2）會帶來一些效能的損失，增加系統的複雜度；3）會使得程式構成複雜，整體性降低，有的情況下，如果設定檔比較複雜，比較大

上一篇，我們建立了一個可用的模型，但我們也看到了它的不足，下面，我們就來繼續完善這個模型：1、首先，因為委託的目的其實是為了與附加責任類進行互動，而掛接了委託的附加責任類才會收到訊息，從這點來看，是一個非常典型的觀察者模式應用情境，因此我們覺得引入這個模式，好處是觀察註冊有專門的類來負責管理，在這裡是代理類行使這個責任（後面的模型會轉到代理類工廠），二是附加責任類以類的身份參與，而不再是簡單的掛接委託，這樣做的好處是目標類可以更多的瞭解附加責任類，可以在需要的時候對觀察者身份進行鑒別，雖然少些自

前一篇我把我自己實現動態封裝的工廠類實現貼了出來，這一篇就來講講為什麼要進行動態代理。理由看起來有以下幾點：1、有的時候我們需要為一些類的方法增加一些額外的責任，因為這些責任是額外的，去改動這些類當然是不好的。      對於這點，大家可以很快的想到用裝飾模式或者代理模式去實現。當然，如果責任固定，而且是事先可預料的，可以在代碼中預先進行處理，例如增加一個    

1）事務都具有兩面性，技術也是事務，技術也具有兩面性      每項技術都有自己的優勢和劣勢，而且針對不同的應用情境，優勢和劣勢還會發生變化，所以在討論技術的優劣的時候應該確定一個相對統一的應用範圍。2）事務都是環境相關的，技術也不例外     

接上篇：4、我們知道我們進行動態代理的目的是為了附加責任，也就是在目標類方法執行的時候，我們能增加一些附加的功能。我們前面的模型雖然可以達到這個目的，但通訊資訊不夠。觀察者雖然可以擷取目標類，但無法知道當前執行的方法和參數值，這在有些情況下雖然沒什麼不利，但既然我們的目標其實就是監視目標類的方法的執行，能有目標類執行方法時的方法資訊和當前實際參數的資訊，當然是更好了，為此，我們可以專門增加一個參數型來封裝這些，便於調用統一:  public interface

前一篇，我們知道可以利用委託和代理來實現為目標類增加額外責任，這裡我們先用一個簡單的例子說明如何去實現.//目標類，有3個公用方法，但由於非虛方法無法繼承，所以能夠切入的只有2個公用虛方法。雖然從生產代理的角度來講，非虛公用方法也可以截獲，//但要求代理類重寫該方法，而一旦重寫，根據方法的調用規則，在用目標類型調用這個方法時，其實是調不到代理類中的這個方法的，所以就沒有機會截獲和監視。public class AClass    {        public virtual void

我們知道，程式設計語言是用來表達電腦執行邏輯的，程式設計語言本身就包含了語素，語義，文法，語素是語言基本的符號，語義是描述語素的意義，而文法則是使用這種語言的規範，其實就是一種互動約定。我們在使用程式設計語言時其實也需要充分利用這種特性或者思想，在程式設計語言的基礎上，建立自己的商務邏輯語言，充分利用契約（就是約定或者標準）來簡化系統的業務處理。比如在很多Entity Framework中都有實體概念性模型到物理模型的映射，維護量其實是相當大的，如果公司自己做實體架構，就完全沒必要維護這種映射，

接上一篇，我們繼續來完善這個模型，我們為附加責任類定義了一個介面，這樣，只要實現這個介面的類都可以註冊，接收代理類的調用通知；同時為了更好的互動，我們還定義了一個調用參數介面，和一個具體的調用參數類，接下來，我們再看看代理類：/// <summary>    /// 代理類，從AClass繼承.    /// </summary>    public class ProxyAClass1 : AClass    {              private AClass

Spring當然不僅僅只包括我們前面看到的這些技術，但其核心的思想主要是IOC+AOP這兩塊。在前面的幾塊中我們著重講了AOP,最後簡單介紹了一下IOC.這個系列介紹到這兒，基本涉及了Spring主要思想和技術，並建立了自己的一個簡單的AOP模型。（一）我們首先來看看我們用到了那些關鍵性技術：1) 動態編譯或IL指令注入    架構提供了這種技術的類庫支援，如果沒有這種庫的支援，要完成AOP編程，難度非常的大;2) 中繼資料和反射機制     在IOC和AOP中都有用到，這已經是在.net

libevent源碼深度剖析八——整合訊號處理張亮      現在我們已經瞭解了libevent的基本架構：事件管理架構和事件主迴圈。上節提到了libevent中I/O事件和Signal以及Timer事件的整合，這一節將分析如何將Signal整合到事件主迴圈的架構中。1 整合策略——使用socket pair      前一節已經做了足夠多的介紹了，基本方法就是採用“訊息機制”。在libevent中這是通過socket pair完成的，下面就來詳細分析一下。      Socket