题目---银行帐户管理系统

//注意：不用if else语句的前提是状态的流动按照一定的规律来运作，就像head first里面的糖果机，状态1：没25分钱 ----投入25分（动作）--->状态2：有25分钱，这些状态之间可以根据逻辑来判断。。。但是如果状态的流动是根据随机或者人的意愿的话，那么if/else语句不可避免

下面题目是CSDN上面抄过来的。。。。

一个假象的银行帐户管理系统中: 

*   帐户(Account)分为普通帐户,VIP帐户和信用卡帐户三种. 
*   每个帐户都可以执行取钱,存钱,注销三种操作 
*   关于取钱操作的细节: 
          普通帐户每次取钱限额为1000元,不能透支 
            VIP帐户每次取钱限额为3000元,不能透支 
            信用卡帐户每次取钱限额为3000元,可以透支 
*   另外每个帐户有四种可能的状态：新建、正常、冻结、挂失 
*   帐号处于不同状态时对于上面提到的三种操作会产生影响： 
            新建状态时不能执行注销操作 
            挂失状态时不能执行存钱、取钱操作 
            冻结状态时不能执行存钱、取钱、注销操作 

下面有一种设计。。。是我所想的。。但是不合理
interface   Account   {   ...   } 
class   GeneralAccount   implements   Account   {   ...   } 
class   VipAccount   implements   Account   {   ...   } 
class   CreditCardAccount   implements   Account   {   ...   } 

不合理之处在于：我的帐户显然可以动态的进行变化，只要吝啬的我愿意多付那么一点点的服务费...但是当我的帐户开始转型时，系统无法让一个GeneralAccount自动转变为VipAccount。。。，所以用户的帐户类型应该用状态来描述，而不是抽象成类。。。


除了取钱以外的其他操作似乎都与不同类型的帐户无关
所以在设计的时候，帐户里面只要绑定取钱一个动作
interface   AccountType   { 
    Money   get(int   amount); 
} 

class   GeneralType   implements   AccountType   { 
    Money   get(int   amount)   {   ...   } 
} 

class   VipType   implements   AccountType   { 
    Money   get(int   amount)   {   ...   } 
} 

class   CreditCardType   implements   AccountType   { 
    Money   get(int   amount)   {   ...   } 
} 

class   Account   { 
    private   String   name; 
    private   String   password; 
    private   AccountType   type; 
    
    Account(int   typeCode)   { 
    } 
    
    void   changeType(int   newTypeCode)   { 
    } 
    
    boolean   logout()   {   ...   } 
    boolean   save(Money   m)   {   ...   } 
    
    Money   get(int   amount)   { 
        Money   result   =   type.get(amount); //这个动作与类型相关，所以委托类型来完成
        return   result; 
    } 
} 

//====================下面是用判断还是策略模式呢？===============
接着那个牛人分析了一下如何实现类型的初始化和类型的转换 
Account(int   typeCode)   { 
    setType(int   typeCode); 
    //   ...other   init   handles 
} 

void   changeType(int   newTypeCode)   { 
    //   do   something   before   change   type... 
    setType(newTypeCode); 
    //   do   something   after   change   type... 
} 

private   void   setType(int   typeCode)   { 
    //   这里假设， 
    //   0代表普通帐户， 
    //   1代表VIP帐户 
    //   2代表信用卡帐户 
    switch   (typeCode)   { 
        case   0:   
            type   =   new   GeneralType(); 
            break; 
        case   1:   
            type   =   new   VipType(); 
            break; 
        case   2: 
            type   =   new   CreditCardType(); 
            break; 
        default: 
            throw   new   AccountTypeException( "Error   account   type   code:   "   +   typeCode); 
    } 
} 
============或者===============================
使用策略模式
当然这里也可以采用策略类来动态确定类型，比如 
Account(AccountType   aType)   {   type   =   aType;   } 
void   changeType(AccountType   newType)   {   type   =   newType;   } 


//状态引用类和状态类本身应该是一种强耦合的关系，所以将这种初始化的任务交给Account自己来维护是合理的，而且这样的switch   or   if/else语句并不冗长
.但是策略模式：由于将选择与初始化帐户类型的操作权利移交到外部的控制类中，那么控制类必定要做出同样的条件选择，而且还必须完全了解帐户类型，帐户和帐户类型之间的互相了解是合情合理的，但外部控制类是否也必须对帐户类型一清二楚就有待定夺了。。。 

//接下来，那个牛人说道：其次，这里的状态只有四种，而且规则并不复杂，我们需要进行抽象或硬要添加某种模式无非是出于以下几种目的 
1。过多的条件选择。。。注意，注意，“条件选择”不是重点。。。“过多的”才是重点 
2。条件选择路径下的各个业务逻辑（算法）异常复杂，但通常即使是仅仅将那些令人作呕的实现逻辑提炼（重构）出来组成一些private   mehtod也就够用了 
3。最可能必须要采用某种策略来降低耦合的目的是因为过多的变化，如果状态的个数是不确定的，或者状态的实现是天马行空的。。。（业务人员通常精于此道），那么采取某种策略将不变与变化隔离是有必要的。 

注意到：基于 "似乎不同状态的帐户在限制某些操作时，对所有的类型都采取了统一的动作

有三种状态，每种状态对应了不同的取钱操作，这里使用状态模式。。。，这里的状态只影响能不能取钱，但是怎么取钱还是要问帐户类型。。。

Account   { 
    private   AccountState   state; 
     private   AccountType   type; 

    Money   get(int   amount,AccountType  type )   { 
        return   state.get(amount,type); //这里改变了
    } 
    ... 
} 
interface   AccountState   { 
    boolean   logout(); 
    boolean   save(Money   m); 
    Money   get(int   amount,AccountType  type ); //如果能取钱,再委托类型来取钱
}