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

[code]


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

下面题目是优快云上面抄过来的。。。。

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

* 帐户(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 ); //如果能取钱,再委托类型来取钱
}


[/code]