怎样才能开发出好的软件（五）完

楼主^#

更多发布于：2011-12-30 18:01

[] 1


	中介绍了结构型模式，这一节就来说一下行为型模式行为型模式：观察者模式、模板方法模式、命令模式、状态模式、职责链模式、解释器模式、中介者模式、访问者模式、策略模式、备忘录模式、迭代器模式。观察者模式：图片：101_3710_0d1478526cb2fb1.gif 观察者模式定义了一种一对多的依赖关系，让多个观察者同时监听某一个主题对象。这个主题对象在发生变化时，会通知所有观察者，使他们能够自动更新自己。当一个对象改变需要同时改变其他对象，而且不知道具体有多少对象有待改变时就应该考虑使用观察者模式了。其实观察者模式的工作就是解耦，让耦合的双方都依赖于抽象，而不是依赖于具体，从而使他们各自的变化不会影响另一边的变化。模板方法模式：图片：101_3710_3465b9670215dc5.gif 模板方法模式定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。其实就是通过把不变的行为搬到超类中，去除子类中的重复代码。何时使用他就显而易见了，当不变的喝可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现，这时候我们就可以用模板方法模式，将这些重复的行为搬到一个单一的地方，也就是超类中，这样就提高了代码的复用率。命令模式：图片：101_3710_00e1818b8b598cf.gif 命令模式就是将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。它将调用操作的对象与知道如何实现该操作的对象解耦（服务员与烤肉串者），这就意味着可以在这两者之间处理很多事，比如发送者发送完请求就完事了，具体怎么做是我的事，我可以在不同的时刻指定、排列和执行请求。还可以在实施操作前将状态存储起来，以便支持取消/重做的操作。还可以记录整个操作日志，以便以后可以在系统出问题是查找原因或恢复重做。当然这就意味着支持事务，要么所有的命令全部执行成功，要么恢复到什么也没执行的状态。敏捷开发的原则告诉我们，不要为了代码添加基于猜测的、实际不需要的功能。如果不清楚一个系统是否需要命令模式，一般就不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义。状态模式：图片：101_3710_a8da4e480d9a225.gif 状态模式是当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。它主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况，把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。当然，如果这个状态判断很简单，就没有必要用状态模式了。当一个对象的行为取决于他的状态，并且它必须在运行时刻根据状态改变他的行为时就可以考虑使用状态模式了。状态模式的好处就是他将与特定状态有关的行为放到一个ConcreteState中，所以通过定义新的子类就可以很方便的增加新的状态和转换了。有了状态模式就省略了判断状态转换的条件了，其实也不是省略了，只不过是把这个判断的条件都转移到ConcreteState中了。职责链模式：图片：101_3710_94c851690c1d083.gif 职责链模式就是使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系，将这个对象连成一条链，并沿着这条链传递该请求，知道有一个对象处理它为止。每一个处理者类都有一个设置下一个后继者的方法和一个处理请求的方法，这两个方法就保证了一个处理请求链存在的可能。这种模式使得接收者和发送者都没有对方的明确信息，并且链中的对象也不知道链的结构，它们只需要保持一个指向后继者的引用，从而大大降低了耦合度，并且可以随时改变或者增加处理一个请求的结构，增强了灵活性。但是需要注意的是有可能一个请求到了链的末端都没有得到处理，所以事先要考虑全面。剩下的几个行为型设计模式留到后面再说