• <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方法中,完成特定的任務。可以說,這是一個非常簡單的模式。
            《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 楊粼波 閱讀(937) 評論(0)  編輯 收藏 引用

            久久99精品久久只有精品| 99久久无码一区人妻| 香蕉久久夜色精品国产2020| 怡红院日本一道日本久久 | 久久99精品久久久久久久久久| 麻豆一区二区99久久久久| 99久久国语露脸精品国产| 久久久噜噜噜久久中文字幕色伊伊| 久久无码专区国产精品发布| 亚洲国产成人久久精品影视| 久久久久久久久久久久久久| 久久综合狠狠综合久久激情 | 国产激情久久久久影院老熟女| 久久影院午夜理论片无码 | 少妇被又大又粗又爽毛片久久黑人 | 久久久久久精品久久久久| 久久人人爽人人爽人人片av麻烦| 久久久久久国产精品免费无码| 精品久久久久久久中文字幕| 久久久久亚洲AV无码专区首JN | 久久久久久a亚洲欧洲aⅴ| 最新久久免费视频| 99久久国产亚洲高清观看2024| 性欧美大战久久久久久久久| 日韩精品无码久久一区二区三| 久久久久国产精品| 7777久久亚洲中文字幕| 蜜臀久久99精品久久久久久小说| 亚洲精品NV久久久久久久久久| 国产精品美女久久久久av爽| 国内精品久久久久| 久久精品人人做人人爽97| 99久久夜色精品国产网站| 色综合久久久久综合99| 久久丝袜精品中文字幕| 久久强奷乱码老熟女网站| 欧美激情精品久久久久久久| 久久久久99精品成人片| 久久久久香蕉视频| 一本久道久久综合狠狠躁AV| 狠狠色丁香婷婷久久综合五月|