无奈朝来寒雨晚来风 的博客

1) 将请求和处理分开，实现解耦，提高系统的灵活性2) 简化了对象，使对象不需要知道链的结构3) 性能会受到影响，特别是在链比较长的时候，因此需控制链中最大节点数量，一般通过在Handler中设置一个最大节点数量，在setNext()方法中判断是否已经超过阀值，超过则不允许该链建立，避免出现超长链无意识地破坏系统性能4) 调试不方便。采用了类似递归的方式，调试时逻辑可能比较复杂5) 最佳应用场景：有多个对象可以处理同一个请求时，比如：多级请求、请假/加薪等审批流程、Java Web中Tomca

1) 策略模式的关键是：分析项目中变化部分与不变部分2) 策略模式的核心思想是：多用组合/聚合 少用继承；用行为类组合，而不是行为的继承。更有弹性3) 体现了“对修改关闭，对扩展开放”原则，客户端增加行为不用修改原有代码，只要添加一种策略（或者行为）即可，避免了使用多重转移语句（if..else if..else）4) 提供了可以替换继承关系的办法： 策略模式将算法封装在独立的Strategy类中使得你可以独立于其Context改变它，使它易于切换、易于理解、易于扩展5) 需要注意的是：每添加

状态模式的注意事项和细节1) 代码有很强的可读性。状态模式将每个状态的行为封装到对应的一个类中2) 方便维护。将容易产生问题的if-else语句删除了，如果把每个状态的行为都放到一个类中，每次调用方法时都要判断当前是什么状态，不但会产出很多if-else语句，而且容易出错3) 符合“开闭原则”。容易增删状态4) 会产生很多类。每个状态都要一个对应的类，当状态过多时会产生很多类，加大维护难度5) 应用场景：当一个事件或者对象有很多种状态，状态之间会相互转换，对不同的状态要求有不同的行为的时候

解释器模式的注意事项和细节1) 当有一个语言需要解释执行，可将该语言中的句子表示为一个抽象语法树，就可以考虑使用解释器模式，让程序具有良好的扩展性2) 应用场景：编译器、运算表达式计算、正则表达式、机器人等3) 使用解释器可能带来的问题：解释器模式会引起类膨胀、解释器模式采用递归调用方法，将会导致调试非常复杂、效率可能降低.

1) 给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态2) 实现了信息的封装，使得用户不需要关心状态的保存细节3) 如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存, 这个需要注意4) 适用的应用场景：1、后悔药。 2、打游戏时的存档。 3、Windows 里的 ctri + z。4、IE 中的后退。 4、数据库的事务管理5) 为了节约内存，备忘录模式可以和原型模式配合使用

中介者模式的注意事项和细节中介者模式的注意事项和细节1) 多个类相互耦合，会形成网状结构, 使用中介者模式将网状结构分离为星型结构，进行解耦2) 减少类间依赖，降低了耦合，符合迪米特原则3) 中介者承担了较多的责任，一旦中介者出现了问题，整个系统就会受到影响4) 如果设计不当，中介者对象本身变得过于复杂，这点在实际使用时，要特别注意

观察者模式的好处1) 观察者模式设计后，会以集合的方式来管理用户(Observer)，包括注册，移除和通知。2) 这样，我们增加观察者(这里可以理解成一个新的公告板)，就不需要去修改核心类WeatherData不会修改代码，遵守了ocp原则。

迭代器模式的注意事项和细节 优点1) 提供一个统一的方法遍历对象，客户不用再考虑聚合的类型，使用一种方法就可以遍历对象了。2) 隐藏了聚合的内部结构，客户端要遍历聚合的时候只能取到迭代器，而不会知道聚合的具体组成。3) 提供了一种设计思想，就是一个类应该只有一个引起变化的原因（叫做单一责任原则）。在聚合类中，我们把迭代器分开，就是要把管理对象集合和遍历对象集合的责任分开，这样一来集合改变的话，只影响到聚合对象。而如果遍历方式改变的话，只影响到了迭代器。4) 当要展示一组相似对象，或者遍

访问者模式的注意事项和细节 优点1) 访问者模式符合单一职责原则、让程序具有优秀的扩展性、灵活性非常高2) 访问者模式可以对功能进行统一，可以做报表、UI、拦截器与过滤器，适用于数据结构相对稳定的系统 缺点1) 具体元素对访问者公布细节，也就是说访问者关注了其他类的内部细节，这是迪米特法则所不建议的, 这样造成了具体元素变更比较困难2) 违背了依赖倒转原则。访问者依赖的是具体元素，而不是抽象元素3) 因此，如果一个系统有比较稳定的数据结构，又有经常变化的功能需求，那么访问者模式就是比

1) 将发起请求的对象与执行请求的对象解耦。发起请求的对象是调用者，调用者只要调用命令对象的execute()方法就可以让接收者工作，而不必知道具体的接收者对象是谁、是如何实现的，命令对象会负责让接收者执行请求的动作，也就是说：”请求发起者”和“请求执行者”之间的解耦是通过命令对象实现的，命令对象起到了纽带桥梁的作用。2) 容易设计一个命令队列。只要把命令对象放到列队，就可以多线程的执行命令3) 容易实现对请求的撤销和重做4) 命令模式不足：可能导致某些系统有过多的具体命令类，增加了系统的复杂

模板方法模式的注意事项和细节1) 基本思想是：算法只存在于一个地方，也就是在父类中，容易修改。需要修改算法时，只要修改父类的模板方法或者已经实现的某些步骤，子类就会继承这些修改2) 实现了最大化代码复用。父类的模板方法和已实现的某些步骤会被子类继承而直接使用。3) 既统一了算法，也提供了很大的灵活性。父类的模板方法确保了算法的结构保持不变，同时由子类提供部分步骤的实现。4) 该模式的不足之处：每一个不同的实现都需要一个子类实现，导致类的个数增加，使得系统更加庞大5) 一般模板方法都加上fi

Cglib代理模式的基本介绍1) 静态代理和JDK代理模式都要求目标对象是实现一个接口,但是有时候目标对象只是一个单独的对象,并没有实现任何的接口,这个时候可使用目标对象子类来实现代理-这就是Cglib代理2) Cglib代理也叫作子类代理,它是在内存中构建一个子类对象从而实现对目标对象功能扩展, 有些书也将Cglib代理归属到动态代理。3) Cglib是一个强大的高性能的代码生成包,它可以在运行期扩展java类与实现java接口.它广泛的被许多AOP的框架使用,例如Spring AOP，实现

 享元模式的注意事项和细节享元模式的注意事项和细节1) 在享元模式这样理解，“享”就表示共享，“元”表示对象2) 系统中有大量对象，这些对象消耗大量内存，并且对象的状态大部分可以外部化时，我们就可以考虑选用享元模式3) 用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象，用HashMap/HashTable存储4) 享元模式大大减少了对象的创建，降低了程序内存的占用，提高效率5) 享元模式提高了系统的复杂度。需要分离出内部状态和外部状态，而外部状态具有固化特性，不应该随着

外观模式的注意事项和细节1) 外观模式对外屏蔽了子系统的细节，因此外观模式降低了客户端对子系统使用的复杂性2) 外观模式对客户端与子系统的耦合关系，让子系统内部的模块更易维护和扩展3) 通过合理的使用外观模式，可以帮我们更好的划分访问的层次4) 当系统需要进行分层设计时，可以考虑使用Facade模式5) 在维护一个遗留的大型系统时，可能这个系统已经变得非常难以维护和扩展，此时可以考虑为新系统开发一个Facade类，来提供遗留系统的比较清晰简单的接口，让新系统与Facade类交互，提高复用性

/抽象类，也可以是接口或者一个实体类 public abstract class OrganizationComponent {// 名字 private String des;// 说明 //不能做成抽象方法，因为有的子类不需要实现 add和remove 方法 protected void add(OrganizationComponent organizationComponent) {//默认实现 throw new UnsupportedOperationException();

核心思想是装饰者和被装饰者都继承同一个父类，然后装饰者利用组合加继承递归装饰被装饰者

1) 桥接模式(Bridge模式)是指：将实现与抽象放在两个不同的类层次中，使两个层次可以独立改变。2) 是一种结构型设计模式3) Bridge模式基于类的最小设计原则，通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来，从而可以保持各部分的独立性以及应对他们的功能扩展

* 思路分析： 目标角色 Controller 有着多种实现子类，一一对应对应着 适配器角色 HandlerAdapter的实现子类，被适配角色。当 DispatchServlet.doDispatch()方法被调用时，会先获取一个 目标角色的实现子类 比如 HttpController， 这时 调用getController 方法， 去匹配对应的适配器（适配器角色的实现子类被适配角色），当匹配到了对应的适配器将适配器进行返回，获取到适配器后 调用 handle 方法传入一个Controller，

1) 客户端(使用程序)不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象2) 每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者， 用户使用不同的具体建造者即可得到不同的产品对象3) 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程4) 增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，

1) 创建新的对象比较复杂时，可以利用原型模式简化对象的创建过程，同时也能够提高效率2) 不用重新初始化对象，而是动态地获得对象运行时的状态3) 如果原始对象发生变化(增加或者减少属性)，其它克隆对象的也会发生相应的变化，无需修改代码4) 在实现深克隆的时候可能需要比较复杂的代码5) 缺点：需要为每一个类配备一个克隆方法，这对全新的类来说不是很难，但对已有的类进行改造时，需要修改其源代码，违背了 ocp 原则，这点请同学们注

1) 工厂模式的意义将实例化对象的代码提取出来，放到一个类中统一管理和维护，达到和主项目的依赖关系的解耦。从而提高项目的扩展和维护性。2) 三种工厂模式 (简单工厂模式、工厂方法模式、抽象工厂模式)3) 设计模式的依赖抽象原则创建对象实例时，不要直接 new 类, 而是把这个new 类的动作放在一个工厂的方法中，并返回。有的书上说，变量不要直接持有具体类的引用。 不要让类继承具体类，而是继承抽象类或者是实现interface(接口)不要覆盖基类中已经实现的方法

代码示例//测试 Singleton instance = Singleton . getInstance();} } //饿汉式(静态变量) class Singleton {//1. 构造器私有化, 外部能 new private Singleton() {} //2.本类内部创建对象实例 private final static Singleton instance = new Singleton();

uml类图

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础(即:设计模式为什么这样设计的依据) 设计模式常用的七大原则有:1、单一职责原则 ，2、 接口隔离原则，3、依赖倒转(倒置)原则，4、里氏替换原则，5、开闭原则，6、 迪米特法则，7、 合成复用原则。