攀升·Uranus


Something Different,Something New
数据加载中……

Command Pattern: We used but we didn't recognize


        Class A wanna class B do what he want to (command). Simple way, invoke B's method, that's a good idea, but don't follow the OO principle: decouple

How to do it?  

        Firstly, B is a stable class; he can in charge of all his responsibility. Maybe there are too many classes like B that A wants to invoke. So how to do it, A composition or aggregation all classes that he needs? Of course not, too much dependence with A. So let’s think about this with OO principle: Encapsulate What Varies.
 

       There are many unpredictable commands that are the variety in this case. We need to encapsulate the command and plugin to A. So at that time, A just knows he is invoking a command, and doesn’t know who and how to execute that command.

       Secondly, how to plugin to A. I don’t wanna talk about DI or Java mechanism. I am handling C++, so just add a method named SetCommand(Command* pCommand) to A, that's fine.

       Lastly, I showed a UML figure 1-1 that described all the means.

     

                                                                Figure 1-1 
       
Everybody’ll shout: that is command pattern.  Yes.

        As the title said: we used but we didn't recognize. So let’s start with its official definition:

        The Command Pattern encapsulate a request as an object, thereby letting you parameterize other objects with different request, queue or log requests, and support undoable operations.

posted on 2009-02-20 21:00 攀升 阅读(1088) 评论(2)  编辑 收藏 引用 所属分类: Design pattern

评论

# re: Command Pattern: We used but we didn't recognize  回复  更多评论   

没事寮什么鸟语呀,rubbish!
2009-02-22 21:14 | cindy

# re: Command Pattern: We used but we didn't recognize  回复  更多评论   

楼上的什么态度呀,你是看不懂吧~
没文化真可怕!
2009-02-22 21:16 | Gaia

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理