Java设计模式

转载自http://blog.csdn.net/column/details/java-designpattern-w.html

MVC\MVP\MVVM模式：
（1）原始MVC模式：MVC中Model层的数据改变时使用观察者模式通知View层，然后View自己请求Model的数据对视图进行更新。
（2）web服务端开发中的MVC模式：服务端接收到来自客户端的请求，服务端通过路由规则把这个请求交由给特定的Controller进行处理，Controller执行相应的业务逻辑，对数据库数据（Model）进行操作，然后用数据去渲染特定的模版，返回给客户端。
然而HTTP协议是单工协议并且是无状态的，服务器无法直接给客户端推送数据。除非客户端再次发起请求，否则服务器端的Model的变更就无法告知客户端。观察者模式被抛弃。
（3）MVP（Passive View模式）：和MVC模式一样，用户对View的操作都会从View交移给Presenter。Presenter同样的会执行相应的业务逻辑，并且对Model进行相应的操作；而这时候Model也是通过观察者模式把自己变更的消息传递出去，但是是传给Presenter而不是View。Presenter获取到Model变更的消息以后，通过View提供的接口更新界面（关键：View需要提供操作界面的接口给Presenter进行调用）。
（4）MVP（Supervising Controller模式）：相对于MVP的Passive View模式（该模式下View非常Passive，它几乎什么都不知道，Presenter让它干什么它就干什么），Supervising Controller模式中，Presenter会把一部分简单的同步逻辑交给View自己去做，Presenter只负责比较复杂的、高层次的UI操作，所以可以把它看成一个Supervising Controller。
（5）MVVM（Model-View-ViewModel）：MVVM的依赖关系和MVP依赖，只不过是把P换成了VM。MVVM的调用关系和MVP一样，但是，在ViewModel当中会有一个叫Binder，或者是Data-binding engine的东西。以前全部由Presenter负责的View和Model之间数据同步操作交由给Binder处理。你只需要在View的模版语法当中，指令式地声明View上的显示的内容是和Model的哪一块数据绑定的。当ViewModel对进行Model更新的时候，Binder会自动把数据更新到View上去，当用户对View进行操作（例如表单输入），Binder也会自动把数据更新到Model上去。这种方式称为：Two-way data-binding，双向数据绑定。可以简单而不恰当地理解为一个模版引擎，但是会根据数据变更实时渲染。也就是说，MVVM把View和Model的同步逻辑自动化了。以前Presenter负责的View和Model同步不再手动地进行操作，而是交由框架所提供的Binder进行负责。只需要告诉Binder，View显示的数据对应的是Model哪一部分即可

java单例模式（双重检查加锁）：只有在第一次实例化时才启用同步机制创建对象，提高了性能。
注意：为什么这里采用双重检查锁定？之前我们不是已经对 student 对象进行了判空操作了么，这里怎么还要进行第二次判空？其实在理解了多线程执行的过程，这个问题也就很好回答了。假定有两个线程 T-0 和 T-1，它们现在同时到达第一个 if (student == null) 判空操作，那么这两个线程都可以进入到 if (student == null) 的内部，因为在此之前对象的访问还没有被锁定；这个时候，如果 T-0 获得了锁，并对对象进行初始化操作，结束后释放锁；然后 T-1 获得了 T-0 释放的锁，如果这里不进行第二次判空操作的话，那么 T-1 也会创建一个对象，这个对象与 T-0 创建的是两个完全不同的对象。而如果这里我们进行了第二次判空操作，那么 T-1 得到的对象不为空，就不会再次创建新的对象了。这个方案设计得十分巧妙，既解决了同步带来的性能开销，又保证了单例模式的构建。

多线程中的单例模式：双重检查锁定，volatile关键字，类初始化，枚举
其中枚举方法是推荐的，它的优点有：
1） 自由序列化；
2） 保证只有一个实例（即使使用反射机制也无法多次实例化一个枚举量）；
3）线程安全。

观察者模式：被观察者在数据有修改的时候去及时通知所有的观察者

装饰器模式：动态地将责任附加到对象上，利用组合维护代码，通过动态地组合对象，可以写新的代码添加新功能，而无须修改现有代码。

工厂模式：为了让程序有一个更好地封装，降低程序模块之间的耦合程度，创建了一个类似工具的类来创建相应的具体类对象

Builder模式：目的是为了将构建复杂对象的过程和它的部件解耦。将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

适配器模式：将一个类的接口1转换成客户希望的另外一个接口2。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作，实际上还是使用的接口1的实现类对象进行工作的，只是看起来是用了接口2的实现类而已。