• <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)  編輯 收藏 引用

            久久精品国产亚洲av麻豆小说 | 亚洲欧美另类日本久久国产真实乱对白| 一级做a爰片久久毛片免费陪| 久久亚洲精品中文字幕三区| 99久久精品日本一区二区免费| 色综合久久久久综合体桃花网| 亚洲国产精品无码久久久不卡| 国产美女亚洲精品久久久综合| 久久SE精品一区二区| 无码伊人66久久大杳蕉网站谷歌 | 日本精品久久久中文字幕| 国产精品99精品久久免费| 久久久久久亚洲Av无码精品专口| 久久超乳爆乳中文字幕| 精品久久久久久中文字幕人妻最新| 久久久精品2019免费观看| 久久超乳爆乳中文字幕| 伊人久久综合热线大杳蕉下载| 曰曰摸天天摸人人看久久久| 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲 | 69国产成人综合久久精品| 久久午夜电影网| 久久久久综合国产欧美一区二区| 一日本道伊人久久综合影| 狼狼综合久久久久综合网| 91精品国产91热久久久久福利| 一本一本久久a久久精品综合麻豆| 精品国产乱码久久久久久人妻| 国产精品久久久久久久久| 久久精品国产福利国产琪琪| 2021国产精品午夜久久| 精品午夜久久福利大片| 亚洲&#228;v永久无码精品天堂久久 | 亚洲国产精品成人AV无码久久综合影院| 国产精品久久久香蕉| 久久久久久免费一区二区三区| 亚洲欧美一级久久精品| 精品久久久久久国产91| 精品久久久无码21p发布| 国产福利电影一区二区三区久久老子无码午夜伦不 | 狠狠色丁香婷婷综合久久来来去|