您的位置:首页 > 其它

22. State 状态(行为型模式)

2007-06-03 14:27 387 查看
问题的提出:对象状态影响对象行为。对象拥有不同的状态,往往会行使不同的行为…

动机(Motivation)
在软件构建过程中,某些对象的状态如果改变,其行为也会随之而发生变化,比如文档处于只读状态,其支持的行为和读写状态支持的行为就可能完全不同。
如何在运行时根据对象的状态来透明地更改对象的行为?而不会为对象操作和状态转化之间引入紧耦合?

意图(Intent)
允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。

例子:

abstract class StatedDocument //抽象类--表达状态及依赖状态的行为

class Document //主逻辑
{
StatedDocument statedDocument;
public void SetStatedDocument(StatedDocument statedDocument)
{
this.statedDocument = statedDocument;
}
public void Handle1()
{
statedDocument.Handle1();
statedDocument = statedDocument.next ;//
}
public void Handle2()
{
statedDocument.Handle2();
}
public void Handle3()
{
statedDocument.Handle3();
}
}

State模式的几个要点
• State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中,在对象状态切换时,
切换相应的对象;但同时维持State的接口,这样实现了具体操作与状态转换之间的解耦。
• 为不同的状态引入不同的对象使得状态转换变得更加明确,而且可以保证不会出现状态不一致的
情况,因为转换是原子性的——即要么彻底转换过来,要么不转换。
• 如果State对象没有实例变量,那么各个上下文可以共享同一个State对象,从而节省对象开销。

讲座中的论点:
//设计模式的目的在于避免编译时依赖,获得运行时依赖
//如果不是有意识的去往某个方向提升,可能写了很多代码,写来写去还是同一水平。
//设计就是源代码,源代码就是设计
//软件的特点:在没有写代码的前期把需求确定。
//敏捷软件开发过程的思想:边走边看。
//项目的前期在拼命重视设计,项目后期不管设计了。正常的应该是后期重视设计,因为前期对需求了解不深,后期对需求了解深。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐