Java 设计模式

代理模式

代理模式的作用是：为其他对象提供一种代理以控制对这个对象的访问。在某些情况下，一个客户不想或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。 

代理模式一般涉及到的角色有： 

抽象角色：声明真实对象和代理对象的共同接口； 

代理角色：代理对象角色内部含有对真实对象的引用，从而可以操作真实对象，同时代理对象提供与真实对象相同的接口以便在任何时刻都能代替真实对象。同时，代理对象可以在执行真实对象操作时，附加其他的操作，相当于对真实对象进行封装。 

真实角色：代理角色所代表的真实对象，是我们最终要引用的对象

代理分类：静态代理比较简单，是由程序员编写的代理类，并在程序运行前就编译好的，而不是由程序动态产生代理类，这就是所谓的静态。动态代理多个主题类对应一个代理类，共享“前处理，后处理”功能，动态调用所需主题，大大减小了程序规模，这就是动态代理模式的特点。

JDK动态代理原理：

1. 创建代理类的源码；
2. 对源码进行编译成字节码；
3. 将字节码加载到内存；
4. 实例化代理类对象并返回给调用者；

cglib 动态代理：

拦截所有目标类方法的调用。

工厂模式

首先，工厂模式是为了解耦：把对象的创建和使用的过程分开。就是Class A 想调用 Class B ，那么A只是调用B的方法，而至于B的实例化，就交给工厂类。

其次，工厂模式可以降低代码重复。如果创建对象B的过程都很复杂，需要一定的代码量，而且很多地方都要用到，那么就会有很多的重复代码。我们可以这些创建对象B的代码放到工厂里统一管理。既减少了重复代码，也方便以后对B的创建过程的修改维护。（当然，我个人觉得也可以把这些创建过程的代码放到类的构造函数里，同样可以降低重复率，而且构造函数本身的作用也是初始化对象。不过，这样也会导致构造函数过于复杂，做的事太多，不符合java 的设计原则。）

由于创建过程都由工厂统一管理，所以发生业务逻辑变化，不需要找到所有需要创建B的地方去逐个修正，只需要在工厂里修改即可，降低维护成本。同理，想把所有调用B的地方改成B的子类B1，只需要在对应生产B的工厂中或者工厂的方法中修改其生产的对象为B1即可，而不需要找到所有的new B（）改为new B1()。

另外，因为工厂管理了对象的创建逻辑，使用者并不需要知道具体的创建过程，只管使用即可，减少了使用者因为创建逻辑导致的错误。

三种工厂模式

1.简单工厂模式

 特点
    1 它是一个具体的类，非接口 抽象类。有一个重要的create()方法，利用if或者 switch创建产品并返回。
    2 create()方法通常是静态的，所以也称之为静态工厂。
 缺点
    1 扩展性差（我想增加一种面条，除了新增一个面条产品类，还需要修改工厂类方法）
    2 不同的产品需要不同额外参数的时候 不支持。

2.工厂方法模式

模式描述
提供一个用于创建对象的接口(工厂接口)，让其实现类(工厂实现类)决定实例化哪一个类(产品类)，并且由该实现类创建对应类的实例。

模式作用
可以一定程度上解耦，消费者和产品实现类隔离开，只依赖产品接口(抽象产品)，产品实现类如何改动与消费者完全无关。

可以一定程度增加扩展性，若增加一个产品实现，只需要实现产品接口，修改工厂创建产品的方法，消费者可以无感知（若消费者不关心具体产品是什么的情况）。
可以一定程度增加代码的封装性、可读性。清楚的代码结构，对于消费者来说很少的代码量就可以完成很多工作。

适用场景
消费者不关心它所要创建对象的类(产品类)的时候。消费者知道它所要创建对象的类(产品类)，但不关心如何创建的时候。

例如：hibernate里通过sessionFactory创建session、通过代理方式生成ws客户端时，通过工厂构建报文中格式化数据的对象。

模式要素
提供一个产品类的接口。产品类均要实现这个接口(也可以是abstract类，即抽象产品)。
提供一个工厂类的接口。工厂类均要实现这个接口(即抽象工厂)。
由工厂实现类创建产品类的实例。工厂实现类应有一个方法，用来实例化产品类。

3.抽象工厂模式

抽象工厂模式的优点
    抽象工厂模式除了具有工厂方法模式的优点外，最主要的优点就是可以在类的内部对产品族进行约束。所谓的产品族，一般或多或少的都存在一定的关联，抽象工厂模式就可以在类内部对产品族的关联关系进行定义和描述，而不必专门引入一个新的类来进行管理。
        
抽象工厂模式的缺点
    产品族的扩展将是一件十分费力的事情，假如产品族中需要增加一个新的产品，则几乎所有的工厂类都需要进行修改。所以使用抽象工厂模式时，对产品等级结构的划分是非常重要的。
    
适用场景
    当需要创建的对象是一系列相互关联或相互依赖的产品族时，便可以使用抽象工厂模式。说的更明白一点，就是一个继承体系中，如果存在着多个等级结构（即存在着多个抽象类），并且分属各个等级结构中的实现类之间存在着一定的关联或者约束，就可以使用抽象工厂模式。假如各个等级结构中的实现类之间不存在关联或约束，则使用多个独立的工厂来对产品进行创建，则更合适一点

委派模式

在常用的23种设计模式中其实面没有委派模式（delegate）的影子，但是在Spring中委派模式确实用的比较多的一种模式，
Spring MVC框架中的DispatcherServlet其实就用到了委派模式，有前辈将其总结为代理模式和策略模式的组合。
下面通过一个简单的实例来总结委派模式：

一个比较实际的例子，就是老板将任务委派给项目经理，项目经理将任务细化，根据每个人擅长的某一方面将细化后的任务分给指定的员工，权衡的方式（策略）有多种，而这个任务项目经理不想干，就将其代理给了各个员工，从这个层面来看委派模式就是策略模式和代理模式的组合。

策略（Strategy）模式

策略模式属于对象的行为模式。其用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。
策略模式把一个系列的算法封装到一个系列的具体策略类里面，作为一个抽象策略类的子类或策略接口的实现类。简单地说：准备一组算法，并将每一个算法封装起来，使它们可以互换。

这个模式涉及到3个角色：
环境(Context)角色：持有一个Strategy抽象策略类或策略接口的引用。
抽象策略(Strategy)角色：这是一个抽象角色，由一个接口或抽象类实现。此角色声明所有的具体策略类需要重写的方法。
具体策略(Concrete Strategy)角色：封装了相关的算法或行为。

原型模式

原型模式的工作原理很简单：将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝自己来实现创建过程。由于在软件系统中我们经常会遇到需要创建多个相同或者相似对象的情况，因此原型模式在真实开发中的使用频率还是非常高的。原型模式是一种“另类”的创建型模式，创建克隆对象的工厂就是原型类自身，工厂方法由克隆方法来实现。

需要注意的是通过克隆方法所创建的对象是全新的对象，它们在内存中拥有新的地址，通常对克隆所产生的对象进行修改对原型对象不会造成任何影响，每一个克隆对象都是相互独立的。通过不同的方式修改可以得到一系列相似但不完全相同的对象。

在原型模式结构图中包含如下几个角色：
Prototype（抽象原型类）：它是声明克隆方法的接口，是所有具体原型类的公共父类，可以是抽象类也可以是接口，甚至还可以是具体实现类。
ConcretePrototype（具体原型类）：它实现在抽象原型类中声明的克隆方法，在克隆方法中返回自己的一个克隆对象。
Client（客户类）：让一个原型对象克隆自身从而创建一个新的对象，在客户类中只需要直接实例化或通过工厂方法等方式创建一个原型对象，再通过调用该对象的克隆方法即可得到多个相同的对象。由于客户类针对抽象原型类Prototype编程，因此用户可以根据需要选择具体原型类，系统具有较好的可扩展性，增加或更换具体原型类都很方便。

模板模式

在模板模式中，抽象类公开了定义的方法/模板来执行它的方法。 它的子类可以根据需要重写方法实现，但调用的方式与抽象类定义的方式相同。 此模式属于行为模式类别。

适用场景

一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。
各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。这是Opdyke和Johnson所描述过的“重分解以一般化”的一个很好的例子。首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
控制子类扩展。模板方法只在特定点调用“hook”操作，这样就只允许在这些点进行扩展。