设计模式概念笔记

• 1.单例模式

确保某一个类只有一个实例，而且自行实例化并向整个系统提供整个实例。

public class Singleton {
    private static volatile  Singleton instance = null ;
    private Singleton() {
    }
    public static Singleton getInstance(){
        if(instance == null ){
            synchronized (Singleton.class){
                if(instance == null){
                    instance = new Singleton();
                }
            }
        }
        return instance ;
    }
}

• 2.工厂模式

定义一个用于创建对象的接口，让子类决定实例化哪一类。工厂方法使一个类的实例化延迟到其子类。

• 3.抽象工厂模式

为创建一组相关或相互依赖的对象提供一个接口，而且无须置顶它们的具体类。

• 4.模块方法模式

定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
模板方法模式就是通过把不变行为搬移到超类，去除子类中的重复代码来提现它的优势。

• 5.建造者模式

将一个复杂对象的构建与他的表示分离，使得同样的构建过程可以创建不同的表示。

主要是用于创建一些复杂的对象，这些对象内部构建间的建造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。、

• 6.代理模式

为其他对象提供一种代理以控制对这个对象的访问。

• 7.原型模式

原型模式实际上就是实现Cloneable接口 重写clone()方法。（浅拷贝，深拷贝）

• 8.中介者模式

用一个中介对象封装一系列的对象交互，中介者使用各对象不需要显示的相互作用，从而使其耦合松散，而且可以独立的改变它们之间的交互。
适用于多个对象之间紧密耦合的情况，紧密耦合： 每个类都与其他类有直接的联系。

• 9.命令模式（顾客-服务员-烧烤人员）

将一个请求封装成一个对象，从而让你使用不同的请求吧客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复。

• 10.责任链模式

一是定义一个请求的处理方法 handleMessage，唯一对外开放的方法；
二是定义一个链的编排方法 setNext，设置下一个处理者；
三是定义了具体的请求者必须实现的两个方法：定义自己能够处理的级别getHandlerLevel 和具体的处理任务 echo。

• 11.装饰模式

动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更加灵活。

• 12.策略模式

定义一组算法，将每个算法都封装起来，并且使它们之间可以 互换。
Context封装角色：
他也叫上下文角色，起承上启下的封装作用，屏蔽高层模块对策略，算法的直接访问，风霜可能变化的部分。

• 13.适配器模式

将一个类的接口变换成客户端所期待的另一种接口，从而使原来因接口不匹配而 无法再一起工作的二个类能够工作在一起。

• 14.迭代器模式（Iterato）
• 15.组合模式

将对象组合成树形结构以表示“部分-整体”的层次结构，使用户对单个对象和组合对象的使用猪油一致性。
只要是树形结构，就考虑使用组合模式。

• 16.观察者模式

定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会有得到通知并被自动更新。
观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。

• 17.外观模式

为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这个一子系统更加容易维护。

• 18.备忘录模式

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将改对象回复到原先保存的状态。
● Originator 发起人角色记录当前时刻的内部状态，负责定义哪些属于备份范围的状态，负责创建和恢复备忘录数据。
● Memento 备忘录角色（简单的 javabean）负责存储 Originator 发起人对象的内部状态，在需要的时候提供发起人需要的内部状态。
● Caretaker 备忘录管理员角色（简单的 javabean）对备忘录进行管理、保存和提供备忘录。

• 19.访问者模式（很蒙）

封装一些作用于某种数据结构中的各元素的
操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

• 20.状态模式

状态模型主要解决的是当控制一个对象状态幻化的条件表达式过于复杂时的情况。吧状态的判断逻辑转移到标识不同状态的一系列类当中，可以吧复杂的逻辑简化。

• 21.解释器模式

没怎么看

• 22.享元模式
• 
• 23.桥梁模式

将抽象和实现解耦，是两者可以独立变化。（抽象类和它派生类用来实现自己的对象）

- 设计原则：

• ●Single Responsibility Principle：单一职责原则

单一职责原则有什么好处：
●类的复杂性降低，实现什么职责都有清晰明确的定义；
● 可读性提高，复杂性降低，那当然可读性提高了；
● 可维护性提高，可读性提高，那当然更容易维护了；
●变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。
ps：接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，环境而异。

• ●Liskov Substitution Principle：里氏替换原则

定义：Functions that use pointers or references to base classes must be able tuse objects of derived classes without knowing it.（所有引用基类的地方必须能透明地使用其子类的对象。）通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
定义中包含的四层含义：
1.子类必须完全实现父类的方法
2.子类可以有自己的个性
3.覆盖或实现父类的方法时输入参数可以被放大如果父类的输入参数类型大于子类的输入参数类型，会出现父类存在的地方，子类未必会存在，因为一旦把子类作为参数传入，调用者很可能进入子类的方法范畴。

• 覆写或实现父类的方法时输出结果可以被缩小父类的一个方法的返回值是一个类型 T，子类的相同方法（重载或覆写）的返回值为 S，那么里氏替换原则就要求 S 必须小于等于 T，也就是说，要么 S 和 T是同一个类型，要么 S 是 T 的子类。
  接口隔离原则接口分为两种：
  实例接口（Object Interface）：Java 中的类也是一种接扣
  类接口（Class Interface）： Java 中经常使用 Interface 关键字定义的接
  隔离：建立单一接口，不要建立臃肿庞大的接口；即接口要尽量细化，同时接口中的方法要尽量少。
  接口隔离原则与单一职责原则的不同：接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。
• ●Dependence Inversion Principle：依赖倒置原则

原始定义：
①高层模块不应该依赖低层模块，两者都应该依赖其抽象；
②抽象不应该依赖细节（实现类）；
③细节应该依赖抽象。
依赖倒置原则在 java 语言中的体现：
①模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
②接口或抽象类不依赖于实现类；
③实现类依赖接口或抽象类。
依赖的三种写法：
①构造函数传递依赖对象（构造函数注入）
②Setter 方法传递依赖对象（setter 依赖注入）
③接口声明依赖对象（接口注入）
使用原则：依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：
①每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
②变量的表面类型尽量是接口或者是抽象类
③任何类都不应该从具体类派生（只要不超过两层的继承是可以忍受的）
④尽量不要复写基类的方法
⑤结合里氏替换原则使用

• ●Open Closed Principle：开闭原则

定义：软件实体应该对扩展开放，对修改关闭。其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。
软件实体：项目或软件产品中按照一定的逻辑规则划分的模块、抽象和类、方法。
变化的三种类型：
①逻辑变化只变化一个逻辑，而不涉及其他模块，比如原有的一个算法是 ab+c，现在需要修改为 ab*c，可以通过修改原有类中的方法的方式来完成，前提条件是所有依赖或关联类都按照相同的逻辑处理。
②子模块变化一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的。
③可见视图变化可见视图是提供给客户使用的界面，如 JSP 程序、Swing 界面等，该部分的变化一般会引起连锁反应（特别是在国内做项目，做欧美的外包项目一般不会影响太大）。可以通过扩展来完成变化，这要看我们原有的设计是否灵活