java 设计模式-职责型模式

单例模式

单例模式只允许一个类存在一个实例
选择创建实例的方法
1.启动时加载（即时不使用到这个也要加载）
其他所有使用的地方都是用这个实例
2.第一次使用使用时加载
在多线程中存在问题，需要使用双重加锁机制来保证实例的唯一。
3.双重加锁机制

/**
* 单例双重加锁Demo
*
*/

public class DoubleCheckLock {

    private static DoubleCheckLock instance ;

    private DoubleCheckLock(){

    }

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

getInstance方法中第一个if(instance == null){}是为了效率，当存在时不必进行加锁的操作，直接返回即可。
synchronized则是为了在多线程中只能有一个线程使用到该方法。当有两个线程同时到达，此时，由于 lock 机制的存在，第一个线程会进入 lock 语句块，并且可以顺利执行 new DoubleCheckLock（）而当第一个线程执行完 new SingleTon（）语句后，便会退出锁定区域，此时，第二个线程便可以进入 lock 语句块。
getInstance方法中第二个if(instance == null){}是为了确保第2个线程进入 lock 语句块是instance还是没有被第一个线程初始化。在执行new。但是此次线程会存在一个问题当第一个线程完成实例化但是第二个线程可能并不能拿到实时实例化的instance，判断instance还是null 会再次进行实例化。此时就应该在instance定义时加上关键词volatile。
参考文章
http://www.cnblogs.com/yanfengfree/p/6271359.html
http://blog.csdn.net/nyist327/article/details/49301401

4.根据实际场景使用

优点：
1.在单例模式中，活动的单例只有一个实例，对单例类的所有实例化得到的都是相同的一个实例。这样就 防止其它对象对自己的实例化，确保所有的对象都访问一个实例
2.单例模式具有一定的伸缩性，类自己来控制实例化进程，类就在改变实例化进程上有相应的伸缩性。
3.提供了对唯一实例的受控访问。
4.由于在系统内存中只存在一个对象，因此可以 节约系统资源，当 需要频繁创建和销毁的对象时单例模式无疑可以提高系统的性能。
5.允许可变数目的实例。
6.避免对共享资源的多重占用。
缺点：
1.不适用于变化的对象，如果同一类型的对象总是要在不同的用例场景发生变化，单例就会引起数据的错误，不能保存彼此的状态。
2.由于单利模式中没有抽象层，因此单例类的扩展有很大的困难。
3.单例类的职责过重，在一定程度上违背了“单一职责原则”。
4.滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为是垃圾而被回收，这将导致对象状态的丢失。
使用注意事项：
1.使用时不能用反射模式创建单例，否则会实例化一个新的对象
2.使用懒单例模式时注意线程安全问题
3.饿单例模式和懒单例模式构造方法都是私有的，因而是不能被继承的，有些单例模式可以被继承（如登记式模式）

http://www.cnblogs.com/damsoft/p/6105122.html

观察者模式

被观察者（一）与观察者（多）的的关系，
1.观察者进行关注（订阅）被观察者。
2.被观察者进行更新操作，并通知所有观察（订阅）者
3.观察（订阅）者做出对应的各自操作。
4（取消观察、订阅）

观察者模式的效果有以下的优点：
　　第一、观察者模式在被观察者和观察者之间建立一个抽象的耦合。被观察者角色所知道的只是一个具体观察者列表，每一个具体观察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体观察者，它只知道它们都有一个共同的接口。
　　由于被观察者和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。
　　第二、观察者模式支持广播通讯。被观察者会向所有的登记过的观察者发出通知。

观察者模式有下面的缺点：
　　第一、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
　　第二、如果在被观察者之间有循环依赖的话，被观察者会触发它们之间进行循环调用，导致系统崩溃。在使用观察者模式是要特别注意这一点。
　　第三、如果对观察者的通知是通过另外的线程进行异步投递的话，系统必须保证投递是以自恰的方式进行的。 （未理解）
　　第四、虽然观察者模式可以随时使观察者知道所观察的对象发生了变化，但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。

调停者模式

类似中介的功能
调停者模式包装了一系列对象相互作用的方式，使得这些对象不必互相明显引用。从而使它们可以较松散地耦合。
当这些对象中的某些对象之间的相互作用发生改变时，不会立即影响其他的一些对象之间的相互作用。从而保证这些相互作用可以彼此独立地变化

1、调停者模式的优点：
（1）适当使用调停者模式可以较少使用静态的继承关系，使得具体被调停者类可以更加容易地被复用。
（2）适当使用调停者模式可以避免同事之间的过渡耦合，使得调停类与被调停者类可以相对独立地演化。
（3）调停者模式将多对多的相互转化为一对多的相互作用，使得对象之间的关系更加易于维护个理解。
（4）调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。

2、调停者模式的缺点：
（1）调停者模式降低了同事对象的复杂性，代价是增加了调停者类的复杂性。当然，在很多情况下，设置 一个调停者并不比不设置一个调停者更好
（2）调停者类经常充满了各个具体同事类的关系协调代码，这种代码常常是不能复用的。因此，具体同事类的 复用是以调停者类的不可复用为代价的。
使用调停者模式貌似要比原本的结构消耗时间，但是却将需求的发起者与执行者之间的强耦合进行了降低，极大的优化了系统内部的维护工作。

　　调停者模式降低的是系统内部的耦合性，而外观模式降低的是系统之间的耦合性。
　　调停者模式更加细化，针对的是系统内部类与类之间的强耦合的解除，外观模式则较为统筹，针对的是整个系统对外的耦合性解除，二者都都有屏蔽复杂性的作用。
　　
个人理解，把各个被调停者的相互之间的调用集成到一个调停者类（被调停者或变得简单明了，调停者类则会越来越复杂）

代理模式

1.静态代理
下面举个案例来解释:
模拟保存动作,定义一个保存动作的接口:IUserDao.java,然后目标对象实现这个接口的方法UserDao.java,此时如果使用静态代理方式,就需要在代理对象(UserDaoProxy.java)中也实现IUserDao接口.调用的时候通过调用代理对象的方法来调用目标对象.
需要注意的是,代理对象与目标对象要实现相同的接口,然后通过调用相同的方法来调用目标对象的方法
/**
* 接口
*/
public interface IUserDao {

void save();

}
/**
* 接口实现
* 目标对象
*/
public class UserDao implements IUserDao {
public void save() {
System.out.println(“—-已经保存数据!—-“);
}
}
/**
* 代理对象,静态代理
*/
public class UserDaoProxy implements IUserDao{
//接收保存目标对象
private IUserDao target;
public UserDaoProxy(IUserDao target){
this.target=target;
}

public void save() {
    System.out.println("开始事务...");
    target.save();//执行目标对象的方法
    System.out.println("提交事务...");
}

}
1.可以做到在不修改目标对象的功能前提下,对目标功能扩展.
2.缺点:
因为代理对象需要与目标对象实现一样的接口,所以会有很多代理类,类太多.同时,一旦接口增加方法,目标对象与代理对象都要维护.
如何解决静态代理中的缺点呢?答案是可以使用动态代理方式

2 jdk动态代理，接口代理
实现InvocationHandler 接口
通过Proxy.newProxyInstance，动态的在内存中构建代理对象
http://rejoy.iteye.com/blog/1627405

3.Cglib代理
但是，JDK的动态代理依靠接口实现，如果有些类并没有实现接口，则不能使用JDK代理，这就要使用cglib动态代理了。（jdk源码判断了有没有实现接口）
这个时候就可以使用以目标对象子类的方式类实现代理,这种方法就叫做:Cglib代理,也叫作子类代理,它是在内存中构建一个子类对象从而实现对目标对象功能的扩展。
实现方法:
1.需要引入cglib的jar文件,但是Spring的核心包中已经包括了Cglib功能,所以直接引入spring-core-3.2.5.jar即可.
2.引入功能包后,就可以在内存中动态构建子类
3.代理的类不能为final,否则报错
4.目标对象的方法如果为final/static,那么就不会被拦截,即不会执行目标对象额外的业务方法.
在Spring的AOP编程中:
如果加入容器的目标对象有实现接口,用JDK代理
如果目标对象没有实现接口,用Cglib代理

/**
 * 目标对象,没有实现任何接口
 */
public class UserDao {

    public void save() {
        System.out.println("----已经保存数据!----");
    }
}

/**
 * Cglib子类代理工厂
 * 对UserDao在内存中动态构建一个子类对象
 */
public class ProxyFactory implements MethodInterceptor{
    //维护目标对象
    private Object target;

    public ProxyFactory(Object target) {
        this.target = target;
    }

    //给目标对象创建一个代理对象
    public Object getProxyInstance(){
        //1.工具类
        Enhancer en = new Enhancer();
        //2.设置父类
        en.setSuperclass(target.getClass());
        //3.设置回调函数
        en.setCallback(this);
        //4.创建子类(代理对象)
        return en.create();

    }

    @Override
    public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
        System.out.println("开始事务...");

        //执行目标对象的方法
        Object returnValue = method.invoke(target, args);

        System.out.println("提交事务...");

        return returnValue;
    }
}

责任链模式

一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一是承担责任，而是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又 把责任向下传的情况。
　　在一个纯的责任链模式里面，一个请求必须被某一个处理者对象所接收；在一个不纯的责任链模式里面，一个请求可以最终不被任何接收端对象所接收。
　　纯的责任链模式的实际例子很难找到，一般看到的例子均是不纯的责任链模式的实现。有些人认为不纯的责任链根本不是责任链模式，这也许是有道理的。但是在实际的系统里，纯的责任链很难找到。如果坚持责任链不纯便不是责任链模式，那么责任链模式便不会有太大意义了。

Filter(过滤器典型的责任链模式)

chain.doFilter(req, res);通过该方法调用下一个filter
FilterChainImpl源码

 public void doFilter(ServletRequest paramServletRequest, ServletResponse paramServletResponse)
    throws IOException, ServletException
  {
    Filter localFilter = (Filter)this.filters.get(this.index++);
    localFilter.doFilter(paramServletRequest, paramServletResponse, this);
  }

以此循环完chain对象的linklist属性。
当条件满足时处理（处理中也包括往后传），不满足时给下一个Filter。（个人感觉这是个不纯的责任链模式，既处理了又往后传了，但是他处理的又只是自己职责内的）。

优点： 1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。
缺点： 1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。

享元模式

享元模式的优点在于它大幅度地降低内存中对象的数量。但是，它做到这一点所付出的代价也是很高的：
　　●　　享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。
　　●　　享元模式将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。
　　享元模式比起工厂，单例，策略，装饰，观察者等模式，其实不算是常用的设计模式，它主要用在底层的设计上比较多，比如之前提到的String类，Integer的valueOf(int)方法等。

　小结：享元模式和单例模式的异同

　　享元是对象级别的, 也就是说在多个使用到这个对象的地方都只需要使用这一个对象即可满足要求, 而单例是类级别的, 就是说这个类必须只能实例化出来一个对象, 可以这么说, 单例是享元的一种特例, 设计模式不用拘泥于具体代码, 代码实现可能有n多种方式, 而单例可以看做是享元的实现方式中的一种, 但是他比享元更加严格的控制了对象的唯一性。

内蕴状态：
　　享元对象的内蕴状态是不会随环境的改变而改变的，是存储在享元对象内部的状态信息，因此内蕴状态是可以共享的，对于任何一个享元对象来讲，它的值是完全相同的。就想上边的“黑子”和“白子”，它代表的状态就是内蕴状态。
　　外蕴状态：
　　享元对象的第二类状态就是外蕴状态，它会随着环境的改变而改变，因此是不可以共享的状态，对于不同的享元对象来说，它的值可能是不同的。享元对象的外蕴状态必须由客户端保存，在享元对象被创建之后，需要使用的时候再传入到享元对象内部，就像五子棋的位置信息，代表的就是享元对象的外蕴状态。
　　所以，享元对象的外蕴状态与内蕴状态是两类相互独立的状态，彼此没有关联。

也有人说享元模式=单例模式+工厂模式+合成模式
个人理解（只有内蕴状态就是一个单利了，加上外蕴状态则是使用了合成模式，工厂模式则是用来创建单例的）