public interface ICustomerTransactions {

 //State-changing methods

 public void createPurchaseRecordForProduct(Long productId)

                     throws CustomerTransactionsSystemException;

 public void loadAllPurchaseRecords()

                     throws CustomerTransactionsSystemException;

 //Behavior method

 public void isCustomerEligibleForDiscount();

}

  这个新的对象维护存储客户交易和决定什么时候客户获得他的十件商品者扣的状态变化和行为方法。它应该是易于创建、测试和维护,因为它只有一个简单的、集中的目的。而一个效率低下的方法是将这些新方法加入到已经存在的ICustomerAccount接口和CustomerAccount对象。如下所示:

public interface ICustomerAccount {

 //State-changing methods

 public void createNewActiveAccount()

                   throws CustomerAccountsSystemOutageException;

 public void loadAccountStatus()

                   throws CustomerAccountsSystemOutageException;

 public void createPurchaseRecordForProduct(Long productId)

                   throws CustomerAccountsSystemOutageException;

 public void loadAllPurchaseRecords()

                   throws CustomerAccountsSystemOutageException;

 //Behavior methods

 public boolean isRequestedUsernameValid();

 public boolean isRequestedPasswordValid();

 public boolean isActiveForPurchasing();

 public String getPostLogonMessage();

 public void isCustomerEligibleForDiscount();

}

  像上面看到的那样,允许对象变成大的责任和目标的仓库将使得它们更加难以阅读,更加容易误解。误解将导致效率的损失,增加业务团队的时间和金钱。简而言之,让对象和它的方法集中的执行小单元的工作更好一些。
 
  习惯4:状态改变方法包含小限度的行为逻辑

  第四个习惯是状态改变方法必须包含小数量的行为逻辑。混合状态改变逻辑和行为逻辑使得软件理解起来更加的困难,因为它增加了在一个地方发生的工作的数量。状态改变方法通常是用来获取或发送数据到一个远程的数据存储设备,因而容易在产品系统中出现问题。诊断一个状态改变方法的系统问题在远程调用被独立的时候更容易一些,这时候它完全不含有行为逻辑。此外,两者的混合还制约了开发过程。例如,getPostLogonMessage()是一个基于accountStatus的值的行为方法:

public String getPostLogonMessage() {

 if("A".equals(this.accountStatus)){

    return "Your purchasing account is active.";

 } else if("E".equals(this.accountStatus)) {

    return "Your purchasing account has " +

           "expired due to a lack of activity.";

 } else {

    return "Your purchasing account cannot be " +

           "found, please call customer service "+

           "for assistance.";

 }

}