这次合作开发过程中我们使用了一些设计模式，经过讨论对其理解深刻不少。之前在学习之中，我本以为自己已经理解了一些设计模式。但在这次的使用过程中，因为各自的理解不一造成了一定的碰撞，之后才发现自己的理解根本就站不住脚。于是，反复经过我们的讨论——实施——再讨论，发现理解的偏差，解决之。然后，才有了目前我们认为的比较稳定的，符合逻辑的理解。本篇博客要说的是我对状态模式和职责链模式的理解。这两个设计模式看上去不一样，实施起来却又貌似很相似，所以不认真的话很容易迷糊。  状态模式：我们用于学生上机时的判断。四个子状态分别为：卡号不存在（CardNoExitStateBLL),卡号存在余额不足(LeastCashStateBLL)，卡号已上机（isOnlineStateBLL),上机成功（SuccessOnlineBLL)。  职责链模式：用于删除用户时，对用户是否还有未结的帐，是否在线的检查判断。四个管理者子类分别为：用户是否在线（IsworkingHandlerBLL),是否有未结账的充值（RechargeIsCheckHandlerBLL),退卡是否有未结的账(CancelCardISCheckHandlerBLL)，注册是否有未结的帐。  相同点： 两个设计模式从类图结构上粗看是完全不一样的。但是实际上在处理一个问题时各个类之间的通信或者说任务递交是一样的，都是链式的一个顺序。特别是在代码上实现时，稍不注意两个模式就会混为一谈，因为图上的巨大区别反应在代码是只有关键的一句或者几句。这种在实现上的理解模糊很让人难受。由于两个模式加起来代码比较长，那么下面配两幅图来说明这个两个模式的区别。 状态模式：实际上子状态是从单个类中独立出去的，因此其整体的功能是一个完整的类的功能。只不过我们把这个类对不同情况的响应写在了一个类中，致使其扩展性不好。所以我们，才把它的不同响应行为独立成状态子类，以赋予它良好的对新需求的扩展性。其本质是，一个类对不同状态的多种不同响应。  职责链模式：实际上是在应对处理一个或者一类问题上的结构性优化。是多个管理者在处理一个问题上森严的等级关系。每个管理者，都只有能处理或者不能处理两种情况。那么，管理者或者说等级关系可能是不稳定的。职责链的本质是，不同的类对同一个问题的反应。  不同点：从以上两幅图可以清楚的看出来，状态模式的子类只负责改变其拥有类的状态属性，而不负责去执行下一个状态的方法。执行还需要通过拥有他的类去调用下个状态子类的方法。而职责链模式的每个管理者则是既负责处理问题也负责请求的递交。这是，我觉得他们最大的区别。这两个模式是从一个问题的不同的角度的处理。一个从问题的角度，一个从处理者的角度。 总结：三个凑皮匠顶个诸葛亮，学习还是需要不同的理解的碰撞，才能够引起新的思考。若不然，则会再自己的思维模式中钉死。