标签：设计模式
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
1.将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便；
2.当一个对象的改变需要同时改变其他对象，而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式；
3.一个抽象有两个方面，其中一方面依赖于另一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用；
总之，观察者模式所做的工作其实就是解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。
使用：当一个对象的改变需要同时改变其他对象，且不知道其他对象的个数的时候，使用观察者模式。
点评：这就是典型的间谍呀，利用间谍来给组织传输情报，组织在根据情报的不同做出相应的调整。
定义一个操作中的算法的骨架，而将一些不走延迟到子类中。模板方法使得子类可以不改变一个算法的结构既可以重定义该算法的某些特定步骤，把不变行为搬到超类，去除子类中重复代码体现它的优势。
代码重复在编程中是常见的现象，如果我们在一个以上的地方看到重复的代码，那么我们就该想办法把他们合二为一，程序就会变的更好。微妙的重复会出现在不同但本质相同的结构或步骤中。
点评：想想我们考试的试题吧，总不能把全国好几百万的考生的试卷重复几百万遍吧，继承的重要性。
将请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，队请求排队或记录请求日志，以及支持可撤销的操作。
将调用操作的对象鱼知道如何实现该操作的对象解耦，这就意味着我们可以在这两者之间做很多的事情，比如在不同的时刻指定，排列和执行请求，支持撤销和重做的操作等。
点评：分工合作，效率才是最好的，做好单一职责。
命令模式VS中介者模式VS观察者模式：三者都是运用中间者来进行类与类之间的沟通，中介者模式是解决许多类之间的相互交互，而命令模式是将调用操作的对象与指导如何实现该操作的对象解耦，主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。中介者仅仅是为了交互的简洁和维护的方便，而命令模式的有点确实可以记录整个操作的日志，以便在日后的系统出问题时查找出原因，支持事务。观察者模式是一种一对多的解耦方式，切多到自己不需要知道。
使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系，将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理为止。
就像我们送快递，我们不能把快递直接给顺丰快递的小哥，而是通过一个点，然后他在给总公司，总公司在根据条件往下分发，一级一级的处理，最后才能到顺丰快递的小哥那里。但是我们却不需要知道到底经过了那些流程，我们只是需要快递，仅此而已。
点评：做好单一职责原则，但是小心邮件地址写错无人收件。
当一个对象的内在状态改变时容许改变其行为，这个对象看起来像是改变了其类。将特定的状态相关的行为都放在一个对象中，由于所有与状态相关的代码都存放在一个具体的状态类中，所以通过定义新的子类可以很容易地增加新的状态和转换。
由于状态的改变行为也会随着状态的变化而变化，所以我们要把状态分开，这样维护才会更用以。
点评：开放-封闭原则真实无处不在。
职责链模式VS状态模式：两者的出现都是在程序需要做出判断的情况下才出现的模式，职责链的需要一个顺序的抉择，而状态模式不需要具体的顺序，但是我们知道程序是不断的变化的，正所谓变才是不变的，所以我们需要把这些分支单独封装的子类中，这样才能让我们动态的去添加或者去修改这些我们需要选择的条件。从而不再需要If或者swith。
给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。可以很容易的扩展和改变文法，
如果一种特定类型的问题发生的频率足够高，那么就可以考虑将该问题的各个实例表述为一个简单语言中的句子，也就是说，通过构建一个解释器，该解释其解释这些句子来解决该问题。这样就不用为没疑问字符串模式都构造一个特定的算法。
点评：专业的东西，咱们就用专业的工具来解决，简单，快捷。
用一个中介对象来封装一些列的交互对象的交互，中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。一般应用于一组对对象，定义良好，但是复杂的方式进行通信的场所。
由于在面向对象中，我们倡导的是单一职责原则，所以在一个项目中可能会存在非常多的类，这样两个类之间的交互就会形成蜘蛛网型的错乱，对于维护是非常不利的。这时我们就可以建立一个中介者，利用中介者来进行类与类之间的交互，为类之间的交互起到搭桥牵线的作用。
点评：我们的操作系统，是不是就是一个中介者模式呢。
表示一个作用于某对象结构中的各个元素的操作，它使你可以再不改变各元素的类的前提下作用于这些元素的新操作。
元素稳定，但是关于元素的状态的变化确实可以变化的，对于元素稳定，但是对于依赖于复杂对象结构的构建的操作就变的非常的容易，仅需要增加一个新的访问者即可在一个对象的结构上增加一个新的操作。
点评：结构足够稳定，运转变化很多，才能容易使用。
策略模式（Strategy）
用来封装几乎任何类型的规则，只要在分析过程中发现有在不同时间需要不同的业务规则，都可以用策略模式，例如商场的打折、积分都可以。
继承提供了一种支持多种算法或行为的方法，我们可以直接生成一个类A的子类B,C,D，从而给他们不同的行为，但是这样会将行为硬编进A中，对于A的维护是非常不利的，但是我们仔细分析就会发现其实他们只是算法或者行为不同，将算法封装在独立的策略类（Strategy）中，使得你可以独立于A类去改变其他的类，使他已于切换，易于理解，易于扩展，这显然是组合要优于继承。
点评：先组合，在继承。
备忘录模式在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以将该对象恢复到原先保存的状态了。
可以避免暴露一些只应由对象A管理却又必须存在对象A之外的信息，备忘录模式把可能很复杂的对象A的内部信息对其他对象屏蔽起来，从而保持了封装边界。
评价：还记得我们当年的游戏吗？
标签：设计模式
原文地址：http://blog.csdn.net/lovemenghaibin/article/details/26085235
