状态模式与策略模式.ppt

软件设计模式——内容状态模式状态模式（续）状态模式（续）这样的代码到底会有什么问题呢？
Checkstate(state)
{
switch(state){
case冻结：
case正常：
……
}
}状态模式（续）状态模式（续）状态模式（续）状态模式（续）参与者
Context：环境类
State：抽象状态类
ConcreteState：具体状态类

状态模式（续）状态模式（续）具体实现（续）
冻结账号类
///<summary>
///冻结账户类
///</summary>
publicclassDeadAccount:state
{

publicoverridedecimalgetBalance(decimald)
{
return0;
}
}具体实现（续）
激活账户类
///<summary>
///激活账户类
///</summary>
publicclassActiveAccount:state
{
publicoverridedecimalgetBalance(decimald)
{
returnd;
}
}具体实现（续集）
交易类
///交易类负责用户交易处理的类
publicclassTrade
{
///保存用户账号信息
privateAccountaccount;
publicAccountVolidateLogin(Accounta)
{
//querythedatabasetovalidatetheuserexists
//ForExample
this.account=newDeadAccount();
returnthis.account;
}
///商业逻辑取款
///<paramname="d"></param>
publicdecimalGetBalance(decimald)
{
returnthis.account.getBalance(d);
}
}具体实现（续）
用户类
///取款人
publicclassUser
{
///用户账号信息
privateAccountaccount;
///交易处理类
privateTradetrade;
publicUser(Accounta,Tradet)
{
this.account=a;
tthis.trade=t;
}
///用户登录类
publicvoidLogin()
{
trade.VolidateLogin(account);
}
///取款
publicdecimalGetBalance(decimald)
{
returntrade.GetBalance(d);
}
}具体实现（续）
客户端代码
classClient
{
staticvoidMain(string[]args)
{
//开始用户取款，默认是激活账户
ActiveAccountaa=newActiveAccount();
Tradet=newTrade();
Useru=newUser(aa,t);
//先登录，后取款
u.Login();
Console.WriteLine(u.GetBalance(100));
Console.ReadLine();
}
}状态模式（续）PM(抬头询问)：有什么困难没有？

我：没有，我已经将代码写好了，您看看。(迅速的将写满代码的稿纸递给PM)

PM(看了一会儿)赞许道：效率不错啊，这么一下子就为公司搞定这个单子。OK，为了表示对你的奖励，周末可以不用加班了。

一年过去了，你已经坐上PM的座位了，你当初写下的那个电梯控制程序也一直运行良好，谁说需求总是会变，一年了那个需求就没有变过，但是不愿意看到的事还是发生了

客户打来电话抱怨说：你的程序运行的很好，但是每次关门的时候非要门完全关上后才能按开门，不能在中途开门，关门也是如此。

思考了下，觉得这个变更是合理的，满口答应了客户的要求。心里想着：不就是加两个状态嘛
修改的代码很快你又交差了，但是这次你有点不爽，当上PM后整天嘴里都是架构、模式，什么开闭原则啊，面向接口编程啊，依赖抽象不依赖具体。可为什么到自己编的时候却总是达不到呢？难道这些OO原则都存在于子虚国？不过心情也不是太差，毕竟完成了客户的需求，还是重复那句古老的经典：如果它还可以运行，就不要动它。
三个月后：
客户：Hello，老兄，我们的电梯接到一个单子，有个电影公司找到我们，要我们提供这样一种电梯，电梯在运行的时候也可以开关门，这样他们就可以拍摄一些特技动作，比如演员跳进正在上升但门是开着的电梯内。
我：…………..
客户：怎么？有困难么？电影公司说要拍一部什么《电梯惊魂》的影片，可能以后有更多的需求变化呢，等电影拍完了有你的好处，呵呵。

我：没有，马上搞定。

我(心里想)：我说怎么瞧这设计都不怎么