State模式技术交流后感

原创 2004年05月22日 12:39:00

1       缘起

       2004519日,部门在大厦2号楼9楼大会议室举行有关OO设计思想以及优秀开发工具的技术交流活动。会上,同事<隐去其名字>主讲了两个主题的内容,分别是“State模式”以及“Dunit单元测试工具”。在前一个主题的讲座和技术交流过程中,大家进行了比较充分的讨论。我本人也有一些感想和心得,特此记录,以飨读者。

 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

2       场景

       以十字转门为例。

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />

十字转门状态

       以上是十字转门的状态迁移图(采用UML)。该图的格式具有如下特点:

1.       采用圆角矩形表达可能的所有状态。注意,状态应该采用形容词表达;

2.       使用单箭头的线段表达迁移,迁移由原状态指向目的状态。迁移线段上的文字包含事件和动作两个部分,并使用”/”分割。

综合上图可知:

n         十字转门共有两个状态,分别为Locked以及Unlocked

n         十字转门共有两种事件,分别为PassCoin

n         通过各个状态对事件的处理,可以得到四种动作,分别为SetLockedSetUnLockedAlarmThank you。其中,Alarm以及Thank you可看作是对于异常情况的处理。

 

3       初步实现

       简单考虑之后,采用Case来实现以上功能,如:

    Tstate = (stLocked, stUnLocked);

    TeventType = (etPass, etCoin);

   

    case Fstate of

        stLocked:

            case AeventType of

                etPass:

                    DoAlarm;

                etCoin:

                    DoSetUnLocked;

        stUnLocked:

            case AeventType of

                etPass:

                    DoSetLocked;

                etCoin:

                    DoThankYou;

        end;

       可以看到,以上代码通过Case语句的层次嵌套完成了功能。功能尽管已经实现,但我们心里似乎有些不够痛快——是否太繁琐了些?试想如果状态更多,事件也更多,那相应的case语句岂非要写的更长?而且不同状态对不同事件的处理代码集中在一起,造成了不必要的相关性,同时也给代码维护造成了更多笔误的机会(不可否认,逻辑集中也有其好处:阅读代码时方便)。

 

4       模式实现

       上述问题改用State模式来实现,那就是另一种风格和境界了:

十字转门类

       仔细研究上述图,不难发现:

1.  门类(TTurnstile)指向了一个代表其状态的一个具体状态类;

2.  把状态进行抽象,并将所有的事件作为抽象(纯虚)方法,然后为每个状态定义派生类来处理各个事件;

3.  相识关系:门类知道状态抽象类,以及所有的具体状态类;具体状态类没有成员变量,也不知道门类。具体状态类互相不相识;具体状态类仅仅从覆盖方法的参数中知晓当时所对应的门类的实例;

4.  每个具体的状态类可以采用单件方式(Singleton)实现;

上述解决方案的优势体现在:

1.  将状态和控制分开,两条线独立演化,系统的扩展性增强;

2.  状态之间互相不知晓,降低它们的耦合度;

3.  采用类名称以及事件名称,消除了原先的两层Case语句。

另外一个值得思考的问题:

状态的转换和动作的执行应该由谁来完成?在本例中,我认为状态类应该对此负责。因为如果由门类来完成,则该模式的应用就没有真正到位。

门类的职责:存储当前状态;转发事件;执行开门/关门动作;根据要求切换状态;

状态的真正切换还是由状态类来触发——从这个意义上来说,状态之间还是具有一定程度的耦合的——只是这种耦合不是直接的引用关系的耦合,而是通过逻辑关系进行的。

 

5       有关模式

模式是针对特定情况,适合解决特定场景下的特定问题的。一般而言,模式总能带来比较多的好处,但同时,也往往会带来一些缺陷或遗憾。如何取舍,要具体问题具体分析。其宗旨是如何让软件系统扩展性更好、可维护性更好,简单,容易理解。

 

6       其他

6.1   有关数据库持久化框架

数据库缓存

State模式详解--设计模式(15)

State模式来源:         每个人、事物在不同的状态下会有不同表现(动作),而一个状态又会在不同的表现下转移到下一个不同的状态(State)。最简单的一个生活中的例子就是:地铁入口处,如果你...
  • fanyun_01
  • fanyun_01
  • 2016年07月01日 08:51
  • 1607

世界上45种咖啡品尝后感

1. NOVA全调合拿铁咖啡,香味独特,喝的时候也有独特的口味。 2. Q牌新品anytime咖啡 三合一g7速溶,口感较滑,没有过多甜味,回味不错。 3. 缅甸PERMIER 2合1速溶咖啡...
  • qqwswxdo
  • qqwswxdo
  • 2012年05月09日 09:05
  • 929

学习linux后感

学了linux之后总感觉自己思绪乱七八糟的,不知道学了之后有什么用,就自己上网查了查学习linux之后的作用。老师给我们下载了一个《鸟哥的Linux私房菜》这本书,老师说看完这本书之后我们就会成为li...
  • zhao48
  • zhao48
  • 2012年12月25日 19:20
  • 192

初学python后感

之前就知道python的强大,只是还没系统的去学过。 昨天晚上和今天上午几个小时时间把简明教程看了一遍,大致了解了一些python的语法和用法。 python是个脚本语言,动态执行的。 pyth...
  • codingkid
  • codingkid
  • 2011年04月08日 15:49
  • 642

设计模式学习笔记--Strategy、State

最近在看设计模式的,防止遗忘,总结一下,如有不足还望指正! 策略模式:(strategy)定义算法家族,分别封装起来,让他们之间可以相互替换。此模式可以让算法的变化,不影响使用算法的用户。 类图如下:...
  • smartboy_01
  • smartboy_01
  • 2014年12月30日 22:32
  • 551

寻找高手交流编程技术

希望找到志同道合的朋友交流编程。QQ
  • b571013930
  • b571013930
  • 2014年04月27日 22:15
  • 348

观《恶棍天使》后感

今天看了《恶棍天使》,欢笑之余收获很多:每一个人心中都有一个恶棍,也都有一个天使,天使和恶棍相辅相生,对立统一,缺一不可!心中只有恶棍,你会排斥整座城市;心中只有天使,整座城市又会排斥你。正如电影里所...
  • u010983763
  • u010983763
  • 2015年12月26日 21:53
  • 920

初识Arduino ----记录学习Arduino

什么是arduino (翻译自arduino官方介绍) Arduino 是一款便捷灵活、方便上手的开源电子原型平台,包含硬件(各种型号的arduino板)和软件(arduino IDE).她适用于...
  • haoayoua
  • haoayoua
  • 2017年02月21日 09:47
  • 417

[登西岭雪山悟]--记感悟登山与生活的相似性

“每月一游”的计划一直未能实现,中间总有很多的优先的事情要做。工作、生活让我们连放松自己的时间都是奢侈。这次周末本来是打算加班用来调休的,结果周五的电脑说“西岭雪山最后十天免费”又让我打开了徒步出去的...
  • amei113
  • amei113
  • 2015年01月23日 18:23
  • 694

java技术交流

  大家好!有个群可以供java方面的同行交流经验 和技术 群号:77057548
  • whlxjq520
  • whlxjq520
  • 2008年12月27日 13:40
  • 314
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:State模式技术交流后感
举报原因:
原因补充:

(最多只允许输入30个字)