• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            《ASD》設計模式:Command和Active Object

            轉載自:http://likeyesterday.spaces.live.com/Blog/cns!A80F5D17DD9D10BF!597.entry

            Command模式:
            Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. - 《Design Patterns》

            Command模式的關鍵在于只包含一個 Execute方法,子類在實現這個接口時,在Execute方法中,完成特定的任務??梢哉f,這是一個非常簡單的模式。
            《ASD》中提到了該模式的三種用法:
            1. Invoker可以和任意一個Command掛鉤,而且不需要了解這到底是個什么ConcreteCommand,然后在需要的時候調用這個 Command對象的Execute方法就行了。這在消息驅動的的系統中非常常見,每個trigger就是一個invoker。那么如何把Command 和invoker掛鉤呢?方法很多,最cool的方法是在系統外用一個配置文件來指定。這樣不需要重新編譯就可以改變軟件運行的方式??梢詤⒖?Source Insight的界面。Source Insight中可以任意配置菜單項和工具欄按鈕。其實現應該就是應用了這種Command模式。
            2. 上面的方法是否讓人想起了Template模式?有點相像吧。順著這個思路去想,就可以把Command模式應用于Transaction。讓一個類來解決Transaction的init和uninit問題,中間包含一個Command的隊列。這樣就可以把這個隊列中的全部command當作一個 transaction了。這樣的作法可以把Transaction的實現和邏輯分離開來,是很漂亮的實現。同樣的思路,也可以用在類似的問題上,需要 init和uninit,中間有不定量的操作。
            3.如果真的用來解決transaction問題,那么就必須具備roll back的能力。然而這個很容易實現,只要在command類中,添加undo方法就可以了。剩下的活交給invoker來處理。
            4.此外還有一個附帶的好處。command類和一個單獨的execute方法其實很相似,但是command類的對象有生命周期,可以由程序來控制。因此,一個command對象,可以在提交了很長時間以后再批量執行。
             
            除了這些以外,《Design Pattern》還提到了Command模式的其他使用方法。雖然這些方法未必實用,但我還是把它們列在這里:
            1.command對象和command對象的序列都可以serialization。這樣如果軟件被有意或無意的中止(例如crash),在重新啟動后,還可以接續之前沒有完成的任務。
            2.Command模式如果和Composite模式接合,就可以作出MacroCommand。^_^,這個idea雖然很cool,但是可以用到的地方大概不多吧。
             
            Active Object模式不屬于《Design Pattern》23模式。實際上,她是一種特殊的Command Queue。其特殊之處在于:
            1. 隊列的擁有者會順序地執行隊列中所有Command對象的Execute方法。(這個其實不算特殊)
            2.Command對象在自己的Execute方法結束前,可以把一個新的command對象(實際上常常是這個command對象自己)再加到隊列的尾部。
            看出來了嗎,這個隊列有可能不會終止的,他可以一直執行下去。這個可以作為一個應用或者服務的主模塊了,想像一下她可以作多少事情吧。
            《ASP》指出這個模式可以用來在一個線程中處理多任務的問題?。。?^_^ 太cool了。
            如何處理呢?你可以把每個command對象看作是一個任務。他在Execute函數中,處理自己的任務,在任務告一段落時,記錄自己的狀態,然后把自己插入到隊列的尾部,結束Execute方法。當隊列輪完一周后,又會再次執行這個command對象的Execute方法。 ^_^ 很cool吧。
            那么這種方法和多線程的方法相比有什么有缺點呢?
            最大的優點是,所有的command都在同一個線程中,因此切換時,不需要進入內核模式??!超高效?。?!而且,可以有很多很多的command,數量上遠遠超過多線程的數量。
            缺點嘛,是這種方法需要用戶自己來實現調度,另外這其實是一種非剝奪模式的多任務,如果command處理不好,就會連累其它所有的command,因此實際上比多線程要更復雜。(嘿嘿,程序員能夠怕麻煩嗎?)
            還有一點,Active Object運行于單線程,也就是說,她不能享受多處理器或多處理器核心帶來的性能上的改善。
            其實,這最后一點是非常致命的一點。也就是說,在當前intel的超線程CPU機器上,如果系統的負擔并不重的時候。Active Object的效率有可能比多線程更低。
            Anyway,這是一個非常有趣的模式。只是一般的程序員可能沒有機會用到。但是請記住她,也許能有那么一次機會,可一用她來爽上一把。

            posted on 2010-02-28 16:05 楊粼波 閱讀(941) 評論(0)  編輯 收藏 引用

            国产三级久久久精品麻豆三级 | 久久久久久国产精品免费免费| 无码任你躁久久久久久| 香港aa三级久久三级| 国产精品久久影院| 久久国产精品成人免费| 91精品国产91久久综合| 九九久久99综合一区二区| 91精品国产综合久久久久久| 久久人妻少妇嫩草AV无码专区| 人妻丰满AV无码久久不卡| 午夜精品久久久久久毛片| 无码人妻精品一区二区三区久久久 | 国产精品美女久久久久| 丰满少妇人妻久久久久久 | 久久精品九九亚洲精品天堂| 九九99精品久久久久久| 国内精品久久久久久久coent| 亚洲精品高清国产一久久| 久久国产V一级毛多内射| 武侠古典久久婷婷狼人伊人| 久久这里都是精品| 亚洲中文字幕无码久久精品1| 久久热这里只有精品在线观看| 人妻无码久久一区二区三区免费| 久久国产精品成人影院| 999久久久免费国产精品播放| 久久er国产精品免费观看2| 久久精品99无色码中文字幕| 无码人妻久久一区二区三区免费丨 | 欧美一区二区精品久久| 亚洲精品WWW久久久久久| 久久成人国产精品| 久久亚洲国产成人影院网站 | 亚洲第一极品精品无码久久| 久久综合狠狠综合久久激情 | 亚洲成av人片不卡无码久久| 91视频国产91久久久| 香蕉99久久国产综合精品宅男自 | 久久精品国产免费| 久久亚洲国产精品成人AV秋霞|