Java开发中的23种设计模式具体解释

1.   
2.     public static void main(String[] args) {  
3.         SendFactory factory = new SendFactory();  
4.         Sender sender = factory.produce("sms");  
5.         sender.Send();  
6.     }  
7. }  

1.         return new MailSender();  
2.     }  
3.       
4.     public Sender produceSms(){  
5.         return new SmsSender();  
6.     }  
7. }  

1. public class FactoryTest {  
2.   
3.     public static void main(String[] args) {  
4.         SendFactory factory = new SendFactory();  
5.         Sender sender = factory.produceMail();  
6.         sender.Send();  
7.     }  
8. }  

1. public class SendFactory {  
2.       
3.     public static Sender produceMail(){  
4.         return new MailSender();  
5.     }  
6.       
7.     public static Sender produceSms(){  
8.         return new SmsSender();  
9.     }  
10. }  

1. public class FactoryTest {  
2.   
3.     public static void main(String[] args) {      
4.         Sender sender = SendFactory.produceMail();  
5.         sender.Send();  
6.     }  
7. }  

1. public interface Sender {  
2.     public void Send();  
3. }  

1. public class MailSender implements Sender {  
2.     @Override  
3.     public void Send() {  
4.         System.out.println("this is mailsender!");  
5.     }  
6. }  

1. public class SmsSender implements Sender {  
2.   
3.     @Override  
4.     public void Send() {  
5.         System.out.println("this is sms sender!");  
6.     }  
7. }  

1. public class SendMailFactory implements Provider {  
2.       
3.     @Override  
4.     public Sender produce(){  
5.         return new MailSender();  
6.     }  
7. }  

1. public class SendSmsFactory implements Provider{  
2.   
3.     @Override  
4.     public Sender produce() {  
5.         return new SmsSender();  
6.     }  
7. }  

1. public interface Provider {  
2.     public Sender produce();  
3. }  

1. public class Test {  
2.   
3.     public static void main(String[] args) {  
4.         Provider provider = new SendMailFactory();  
5.         Sender sender = provider.produce();  
6.         sender.Send();  
7.     }  
8. }  

1. public class Singleton {  
2.   
3.     /* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟载入 */  
4.     private static Singleton instance = null;  
5.   
6.     /* 私有构造方法，防止被实例化 */  
7.     private Singleton() {  
8.     }  
9.   
10.     /* 静态project方法，创建实例 */  
11.     public static Singleton getInstance() {  
12.         if (instance == null) {  
13.             instance = new Singleton();  
14.         }  
15.         return instance;  
16.     }  
17.   
18.     /* 假设该对象被用于序列化，能够保证对象在序列化前后保持一致 */  
19.     public Object readResolve() {  
20.         return instance;  
21.     }  
22. }  

1. public static synchronized Singleton getInstance() {  
2.         if (instance == null) {  
3.             instance = new Singleton();  
4.         }  
5.         return instance;  
6.     }  

1. public static Singleton getInstance() {  
2.         if (instance == null) {  
3.             synchronized (instance) {  
4.                 if (instance == null) {  
5.                     instance = new Singleton();  
6.                 }  
7.             }  
8.         }  
9.         return instance;  
10.     }  

1. private static class SingletonFactory{           
2.         private static Singleton instance = new Singleton();           
3.     }           
4.     public static Singleton getInstance(){           
5.         return SingletonFactory.instance;           
6.     }   

1. public class Singleton {  
2.   
3.     /* 私有构造方法，防止被实例化 */  
4.     private Singleton() {  
5.     }  
6.   
7.     /* 此处使用一个内部类来维护单例 */  
8.     private static class SingletonFactory {  
9.         private static Singleton instance = new Singleton();  
10.     }  
11.   
12.     /* 获取实例 */  
13.     public static Singleton getInstance() {  
14.         return SingletonFactory.instance;  
15.     }  
16.   
17.     /* 假设该对象被用于序列化，能够保证对象在序列化前后保持一致 */  
18.     public Object readResolve() {  
19.         return getInstance();  
20.     }  
21. }  

1. public class SingletonTest {  
2.   
3.     private static SingletonTest instance = null;  
4.   
5.     private SingletonTest() {  
6.     }  
7.   
8.     private static synchronized void syncInit() {  
9.         if (instance == null) {  
10.             instance = new SingletonTest();  
11.         }  
12.     }  
13.   
14.     public static SingletonTest getInstance() {  
15.         if (instance == null) {  
16.             syncInit();  
17.         }  
18.         return instance;  
19.     }  
20. }  

1. public class SingletonTest {  
2.   
3.     private static SingletonTest instance = null;  
4.     private Vector properties = null;  
5.   
6.     public Vector getProperties() {  
7.         return properties;  
8.     }  
9.   
10.     private SingletonTest() {  
11.     }  
12.   
13.     private static synchronized void syncInit() {  
14.         if (instance == null) {  
15.             instance = new SingletonTest();  
16.         }  
17.     }  
18.   
19.     public static SingletonTest getInstance() {  
20.         if (instance == null) {  
21.             syncInit();  
22.         }  
23.         return instance;  
24.     }  
25.   
26.     public void updateProperties() {  
27.         SingletonTest shadow = new SingletonTest();  
28.         properties = shadow.getProperties();  
29.     }  
30. }  

1. public class Builder {  
2.       
3.     private List<Sender> list = new ArrayList<Sender>();  
4.       
5.     public void produceMailSender(int count){  
6.         for(int i=0; i<count; i++){  
7.             list.add(new MailSender());  
8.         }  
9.     }  
10.       
11.     public void produceSmsSender(int count){  
12.         for(int i=0; i<count; i++){  
13.             list.add(new SmsSender());  
14.         }  
15.     }  
16. }  

1. public class Test {  
2.   
3.     public static void main(String[] args) {  
4.         Builder builder = new Builder();  
5.         builder.produceMailSender(10);  
6.     }  
7. }  

1. public class Prototype implements Cloneable {  
2.   
3.     public Object clone() throws CloneNotSupportedException {  
4.         Prototype proto = (Prototype) super.clone();  
5.         return proto;  
6.     }  
7. }  

1. public class Prototype implements Cloneable, Serializable {  
2.   
3.     private static final long serialVersionUID = 1L;  
4.     private String string;  
5.   
6.     private SerializableObject obj;  
7.   
8.     /* 浅复制 */  
9.     public Object clone() throws CloneNotSupportedException {  
10.         Prototype proto = (Prototype) super.clone();  
11.         return proto;  
12.     }  
13.   
14.     /* 深复制 */  
15.     public Object deepClone() throws IOException, ClassNotFoundException {  
16.   
17.         /* 写入当前对象的二进制流 */  
18.         ByteArrayOutputStream bos = new ByteArrayOutputStream();  
19.         ObjectOutputStream oos = new ObjectOutputStream(bos);  
20.         oos.writeObject(this);  
21.   
22.         /* 读出二进制流产生的新对象 */  
23.         ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());  
24.         ObjectInputStream ois = new ObjectInputStream(bis);  
25.         return ois.readObject();  
26.     }  
27.   
28.     public String getString() {  
29.         return string;  
30.     }  
31.   
32.     public void setString(String string) {  
33.         this.string = string;  
34.     }  
35.   
36.     public SerializableObject getObj() {  
37.         return obj;  
38.     }  
39.   
40.     public void setObj(SerializableObject obj) {  
41.         this.obj = obj;  
42.     }  
43.   
44. }  
45.   
46. class SerializableObject implements Serializable {  
47.     private static final long serialVersionUID = 1L;  
48. }  

我们接着讨论设计模式，上篇文章我讲完了5种创建型模式，这章開始，我将讲下7种结构型模式：适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式。当中对象的适配器模式是各种模式的起源，我们看以下的图：

 适配器模式将某个类的接口转换成client期望的还有一个接口表示，目的是消除因为接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。首先，我们来看看类的适配器模式，先看类图：

核心思想就是：有一个Source类，拥有一个方法，待适配，目标接口时Targetable，通过Adapter类，将Source的功能扩展到Targetable里，看代码：

Adapter类继承Source类，实现Targetable接口，以下是測试类：

输出：

this is original method!
this is the targetable method!

这样Targetable接口的实现类就具有了Source类的功能。

对象的适配器模式

基本思路和类的适配器模式同样，仅仅是将Adapter类作改动，这次不继承Source类，而是持有Source类的实例，以达到解决兼容性的问题。看图：

仅仅须要改动Adapter类的源代码就可以：

測试类：

输出与第一种一样，仅仅是适配的方法不同而已。

第三种适配器模式是接口的适配器模式，接口的适配器是这种：有时我们写的一个接口中有多个抽象方法，当我们写该接口的实现类时，必须实现该接口的全部方法，这明显有时比較浪费，由于并非全部的方法都是我们须要的，有时仅仅须要某一些，此处为了解决问题，我们引入了接口的适配器模式，借助于一个抽象类，该抽象类实现了该接口，实现了全部的方法，而我们不和原始的接口打交道，仅仅和该抽象类取得联系，所以我们写一个类，继承该抽象类，重写我们须要的方法即可。看一下类图：

这个非常好理解，在实际开发中，我们也常会遇到这样的接口中定义了太多的方法，以致于有时我们在一些实现类中并非都须要。看代码：

抽象类Wrapper2：

測试输出：

the sourceable interface‘s first Sub1!
the sourceable interface‘s second Sub2!

达到了我们的效果！

 讲了这么多，总结一下三种适配器模式的应用场景：

类的适配器模式：当希望将一个类转换成满足还有一个新接口的类时，能够使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口就可以。

对象的适配器模式：当希望将一个对象转换成满足还有一个新接口的对象时，能够创建一个Wrapper类，持有原类的一个实例，在Wrapper类的方法中，调用实例的方法即可。

接口的适配器模式：当不希望实现一个接口中全部的方法时，能够创建一个抽象类Wrapper，实现全部方法，我们写别的类的时候，继承抽象类就可以。

7、装饰模式（Decorator）

顾名思义，装饰模式就是给一个对象添加一些新的功能，并且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例，关系图例如以下：

Source类是被装饰类，Decorator类是一个装饰类，能够为Source类动态的加入一些功能，代码例如以下：

測试类：

输出：

before decorator!
the original method!
after decorator!

装饰器模式的应用场景：

1、须要扩展一个类的功能。

2、动态的为一个对象添加功能，并且还能动态撤销。（继承不能做到这一点，继承的功能是静态的，不能动态增删。）

缺点：产生过多相似的对象，不易排错！

8、代理模式（Proxy）

事实上每一个模式名称就表明了该模式的作用，代理模式就是多一个代理类出来，替原对象进行一些操作，比方我们在租房子的时候回去找中介，为什么呢？由于你对该地区房屋的信息掌握的不够全面，希望找一个更熟悉的人去帮你做，此处的代理就是这个意思。再如我们有的时候打官司，我们须要请律师，由于律师在法律方面有专长，能够替我们进行操作，表达我们的想法。先来看看关系图：

依据上文的阐述，代理模式就比較easy的理解了，我们看下代码：

測试类：

输出：

before proxy!
the original method!
after proxy!

代理模式的应用场景：

假设已有的方法在使用的时候须要对原有的方法进行改进，此时有两种办法：

1、改动原有的方法来适应。这样违反了“对扩展开放，对改动关闭”的原则。

2、就是採用一个代理类调用原有的方法，且对产生的结果进行控制。这样的方法就是代理模式。

使用代理模式，能够将功能划分的更加清晰，有助于后期维护！

9、外观模式（Facade）

外观模式是为了解决类与类之家的依赖关系的，像spring一样，能够将类和类之间的关系配置到配置文件里，而外观模式就是将他们的关系放在一个Facade类中，减少了类类之间的耦合度，该模式中没有涉及到接口，看下类图：（我们以一个计算机的启动过程为例）

我们先看下实现类：

User类例如以下：

输出：

start the computer!
cpu startup!
memory startup!
disk startup!
start computer finished!
begin to close the computer!
cpu shutdown!
memory shutdown!
disk shutdown!
computer closed!

假设我们没有Computer类，那么，CPU、Memory、Disk他们之间将会相互持有实例，产生关系，这样会造成严重的依赖，改动一个类，可能会带来其它类的改动，这不是我们想要看到的，有了Computer类，他们之间的关系被放在了Computer类里，这样就起到了解耦的作用，这，就是外观模式！

10、桥接模式（Bridge）

桥接模式就是把事物和其详细实现分开，使他们能够各自独立的变化。桥接的用意是：将抽象化与实现化解耦，使得二者能够独立变化，像我们经常使用的JDBC桥DriverManager一样，JDBC进行连接数据库的时候，在各个数据库之间进行切换，基本不须要动太多的代码，甚至丝毫不用动，原因就是JDBC提供统一接口，每一个数据库提供各自的实现，用一个叫做数据库驱动的程序来桥接即可了。我们来看看关系图：

实现代码：

先定义接口：

分别定义两个实现类：

定义一个桥，持有Sourceable的一个实例：

測试类：

output：

this is the first sub!
this is the second sub!

这样，就通过对Bridge类的调用，实现了对接口Sourceable的实现类SourceSub1和SourceSub2的调用。接下来我再画个图，大家就应该明确了，由于这个图是我们JDBC连接的原理，有数据库学习基础的，一结合就都懂了。

11、组合模式（Composite）

组合模式有时又叫部分-总体模式在处理类似树形结构的问题时比較方便，看看关系图：

直接来看代码：

使用场景：将多个对象组合在一起进行操作，经常使用于表示树形结构中，比如二叉树，数等。

12、享元模式（Flyweight）

享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候能够降低内存的开销，通常与工厂模式一起使用。

FlyWeightFactory负责创建和管理享元单元，当一个client请求时，工厂须要检查当前对象池中是否有符合条件的对象，假设有，就返回已经存在的对象，假设没有，则创建一个新对象，FlyWeight是超类。一提到共享池，我们非常easy联想到Java里面的JDBC连接池，想想每一个连接的特点，我们不难总结出：适用于作共享的一些个对象，他们有一些共同拥有的属性，就拿数据库连接池来说，url、driverClassName、username、password及dbname，这些属性对于每一个连接来说都是一样的，所以就适合用享元模式来处理，建一个工厂类，将上述类似属性作为内部数据，其他的作为外部数据，在方法调用时，当做參数传进来，这样就节省了空间，降低了实例的数量。

看个样例：

看下数据库连接池的代码：

本章是关于设计模式的最后一讲，会讲到第三种设计模式——行为型模式，共11种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、訪问者模式、中介者模式、解释器模式。这段时间一直在写关于设计模式的东西，最终写到一半了，写博文是个非常费时间的东西，由于我得为读者负责，不论是图还是代码还是表述，都希望能尽量写清楚，以便读者理解，我想不论是我还是读者，都希望看到高质量的博文出来，从我本人出发，我会一直坚持下去，不断更新，源源动力来自于读者朋友们的不断支持，我会尽自己的努力，写好每一篇文章！希望大家能不断给出意见和建议，共同打造完美的博文！

先来张图，看看这11中模式的关系：

第一类：通过父类与子类的关系进行实现。第二类：两个类之间。第三类：类的状态。第四类：通过中间类

13、策略模式（strategy）

策略模式定义了一系列算法，并将每一个算法封装起来，使他们能够相互替换，且算法的变化不会影响到使用算法的客户。须要设计一个接口，为一系列实现类提供统一的方法，多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数，关系图例如以下：

图中ICalculator提供允许的方法，
AbstractCalculator是辅助类，提供辅助方法，接下来，依次实现下每一个类：

首先统一接口：

辅助类：

三个实现类：

简单的測试类：

输出：10

策略模式的决定权在用户，系统本身提供不同算法的实现，新增或者删除算法，对各种算法做封装。因此，策略模式多用在算法决策系统中，外部用户仅仅须要决定用哪个算法就可以。

14、模板方法模式（Template Method）

解释一下模板方法模式，就是指：一个抽象类中，有一个主方法，再定义1...n个方法，能够是抽象的，也能够是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用，先看个关系图：

就是在AbstractCalculator类中定义一个主方法calculate，calculate()调用spilt()等，Plus和Minus分别继承AbstractCalculator类，通过对AbstractCalculator的调用实现对子类的调用，看以下的样例：

測试类：

我跟踪下这个小程序的运行过程：首先将exp和"\\+"做參数，调用AbstractCalculator类里的calculate(String,String)方法，在calculate(String,String)里调用同类的split()，之后再调用calculate(int ,int)方法，从这种方法进入到子类中，运行完return num1 + num2后，将值返回到AbstractCalculator类，赋给result，打印出来。正好验证了我们开头的思路。

15、观察者模式（Observer）

包含这个模式在内的接下来的四个模式，都是类和类之间的关系，不涉及到继承，学的时候应该 记得归纳，记得本文最開始的那个图。观察者模式非常好理解，类似于邮件订阅和RSS订阅，当我们浏览一些博客或wiki时，常常会看到RSS图标，就这的意思是，当你订阅了该文章，假设兴许有更新，会及时通知你。事实上，简单来讲就一句话：当一个对象变化时，其他依赖该对象的对象都会收到通知，而且随着变化！对象之间是一种一对多的关系。先来看看关系图：

我解释下这些类的作用：MySubject类就是我们的主对象，Observer1和Observer2是依赖于MySubject的对象，当MySubject变化时，Observer1和Observer2必定变化。AbstractSubject类中定义着须要监控的对象列表，能够对其进行改动：添加或删除被监控对象，且当MySubject变化时，负责通知在列表内存在的对象。我们看实现代码：

一个Observer接口：

两个实现类：

Subject接口及实现类：

測试类：

输出：

update self!
observer1 has received!
observer2 has received!

 这些东西，事实上不难，仅仅是有些抽象，不太easy总体理解，建议读者：依据关系图，新建项目，自己写代码（或者參考我的代码）,依照总体思路走一遍，这样才干体会它的思想，理解起来easy！ 

16、迭代子模式（Iterator）

顾名思义，迭代器模式就是顺序訪问聚集中的对象，一般来说，集合中很常见，假设对集合类比較熟悉的话，理解本模式会十分轻松。这句话包括两层意思：一是须要遍历的对象，即聚集对象，二是迭代器对象，用于对聚集对象进行遍历訪问。我们看下关系图：

这个思路和我们经常使用的一模一样，MyCollection中定义了集合的一些操作，MyIterator中定义了一系列迭代操作，且持有Collection实例，我们来看看实现代码：

两个接口：

两个实现：

測试类：

输出：A B C D E

此处我们貌似模拟了一个集合类的过程，感觉是不是非常爽？事实上JDK中各个类也都是这些主要的东西，加一些设计模式，再加一些优化放到一起的，仅仅要我们把这些东西学会了，掌握好了，我们也能够写出自己的集合类，甚至框架！

17、责任链模式（Chain of Responsibility）
接下来我们将要谈谈责任链模式，有多个对象，每一个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。可是发出者并不清楚究竟终于那个对象会处理该请求，所以，责任链模式能够实现，在隐瞒client的情况下，对系统进行动态的调整。先看看关系图：

Abstracthandler类提供了get和set方法，方便MyHandle类设置和改动引用对象，MyHandle类是核心，实例化后生成一系列相互持有的对象，构成一条链。

输出：

h1deal!
h2deal!
h3deal!

此处强调一点就是，链接上的请求能够是一条链，能够是一个树，还能够是一个环，模式本身不约束这个，须要我们自己去实现，同一时候，在一个时刻，命令仅仅同意由一个对象传给还有一个对象，而不同意传给多个对象。

 18、命令模式（Command）

命令模式非常好理解，举个样例，司令员下令让士兵去干件事情，从整个事情的角度来考虑，司令员的作用是，发出口令，口令经过传递，传到了士兵耳朵里，士兵去运行。这个过程好在，三者相互解耦，不论什么一方都不用去依赖其它人，仅仅须要做好自己的事儿即可，司令员要的是结果，不会去关注究竟士兵是怎么实现的。我们看看关系图：

Invoker是调用者（司令员），Receiver是被调用者（士兵），MyCommand是命令，实现了Command接口，持有接收对象，看实现代码：

输出：command received!

这个非常哈理解，命令模式的目的就是达到命令的发出者和运行者之间解耦，实现请求和运行分开，熟悉Struts的同学应该知道，Struts事实上就是一种将请求和呈现分离的技术，当中必定涉及命令模式的思想！

事实上每个设计模式都是非常重要的一种思想，看上去非常熟，事实上是由于我们在学到的东西中都有涉及，虽然有时我们并不知道，事实上在Java本身的设计之中处处都有体现，像AWT、JDBC、集合类、IO管道或者是Web框架，里面设计模式无处不在。由于我们篇幅有限，非常难讲每个设计模式都讲的非常具体，只是我会尽我所能，尽量在有限的空间和篇幅内，把意思写清楚了，更好让大家明确。本章不出意外的话，应该是设计模式最后一讲了，首先还是上一下上篇开头的那个图：

本章讲讲第三类和第四类。

19、备忘录模式（Memento）

主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，个人认为叫备份模式更形象些，通俗的讲下：如果有原始类A，A中有各种属性，A能够决定须要备份的属性，备忘录类B是用来存储A的一些内部状态，类C呢，就是一个用来存储备忘录的，且仅仅能存储，不能改动等操作。做个图来分析一下：

Original类是原始类，里面有须要保存的属性value及创建一个备忘录类，用来保存value值。Memento类是备忘录类，Storage类是存储备忘录的类，持有Memento类的实例，该模式非常好理解。直接看源代码：

測试类：

输出：

初始化状态为：egg
改动后的状态为：niu
恢复后的状态为：egg

简单描写叙述下：新建原始类时，value被初始化为egg，后经过改动，将value的值置为niu，最后倒数第二行进行恢复状态，结果成功恢复了。事实上我认为这个模式叫“备份-恢复”模式最形象。

20、状态模式（State）

核心思想就是：当对象的状态改变时，同一时候改变其行为，非常好理解！就拿QQ来说，有几种状态，在线、隐身、忙碌等，每一个状态相应不同的操作，并且你的好友也能看到你的状态，所以，状态模式就两点：1、能够通过改变状态来获得不同的行为。2、你的好友能同一时候看到你的变化。看图：

State类是个状态类，Context类能够实现切换，我们来看看代码：

execute the first opt!
execute the second opt!

依据这个特性，状态模式在日常开发中用的挺多的，尤其是做站点的时候，我们有时希望依据对象的某一属性，差别开他们的一些功能，比方说简单的权限控制等。
21、訪问者模式（Visitor）

訪问者模式把数据结构和作用于结构上的操作解耦合，使得操作集合可相对自由地演化。訪问者模式适用于数据结构相对稳定算法又易变化的系统。由于訪问者模式使得算法操作添加变得easy。若系统数据结构对象易于变化，常常有新的数据对象添加进来，则不适合使用訪问者模式。訪问者模式的长处是添加操作非常easy，由于添加操作意味着添加新的訪问者。訪问者模式将有关行为集中到一个訪问者对象中，其改变不影响系统数据结构。其缺点就是添加新的数据结构非常困难。—— From 百科

简单来说，訪问者模式就是一种分离对象数据结构与行为的方法，通过这样的分离，可达到为一个被訪问者动态加入新的操作而无需做其他的改动的效果。简单关系图：

来看看原码：一个Visitor类，存放要訪问的对象，

该模式适用场景：假设我们想为一个现有的类添加新功能，不得不考虑几个事情：1、新功能会不会与现有功能出现兼容性问题？2、以后会不会再须要加入？3、假设类不同意改动代码怎么办？面对这些问题，最好的解决方法就是使用訪问者模式，訪问者模式适用于数据结构相对稳定的系统，把数据结构和算法解耦，
22、中介者模式（Mediator）

中介者模式也是用来减少类类之间的耦合的，由于假设类类之间有依赖关系的话，不利于功能的拓展和维护，由于仅仅要改动一个对象，其他关联的对象都得进行改动。假设使用中介者模式，仅仅需关心和Mediator类的关系，详细类类之间的关系及调度交给Mediator即可，这有点像spring容器的作用。先看看图：

User类统一接口，User1和User2各自是不同的对象，二者之间有关联，假设不採用中介者模式，则须要二者相互持有引用，这样二者的耦合度非常高，为了解耦，引入了Mediator类，提供统一接口，MyMediator为事实上现类，里面持有User1和User2的实例，用来实现对User1和User2的控制。这样User1和User2两个对象相互独立，他们仅仅须要保持好和Mediator之间的关系即可，剩下的全由MyMediator类来维护！基本实现：

user1 exe!
user2 exe!
23、解释器模式（Interpreter）
解释器模式是我们临时的最后一讲，一般主要应用在OOP开发中的编译器的开发中，所以适用面比較窄。

Context类是一个上下文环境类，Plus和Minus各自是用来计算的实现，代码例如以下：

基本就这样，解释器模式用来做各种各样的解释器，如正則表達式等的解释器等等！

输出：this is sms sender!

22、多个工厂方法模式，是对普通工厂方法模式的改进，在普通工厂方法模式中，假设传递的字符串出错，则不能正确创建对象，而多个工厂方法模式是提供多个工厂方法，分别创建对象。关系图：

将上面的代码做下修改，修改下SendFactory类即可，例如以下：

測试类例如以下：

输出：this is mailsender!

33、静态工厂方法模式，将上面的多个工厂方法模式里的方法置为静态的，不须要创建实例，直接调用就可以。

输出：this is mailsender!

整体来说，工厂模式适合：凡是出现了大量的产品须要创建，而且具有共同的接口时，能够通过工厂方法模式进行创建。在以上的三种模式中，第一种假设传入的字符串有误，不能正确创建对象，第三种相对于另外一种，不须要实例化工厂类，所以，大多数情况下，我们会选用第三种——静态工厂方法模式。

2、抽象工厂模式（Abstract Factory）

工厂方法模式有一个问题就是，类的创建依赖工厂类，也就是说，假设想要拓展程序，必须对工厂类进行改动，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，怎样解决？就用到抽象工厂模式，创建多个工厂类，这样一旦须要添加新的功能，直接添加新的工厂类就能够了，不须要改动之前的代码。由于抽象工厂不太好理解，我们先看看图，然后就和代码，就比較easy理解。

请看样例：

两个实现类：

两个工厂类：

在提供一个接口：

測试类：

事实上这个模式的优点就是，假设你如今想添加一个功能：发及时信息，则仅仅需做一个实现类，实现Sender接口，同一时候做一个工厂类，实现Provider接口，就OK了，无需去修改现成的代码。这样做，拓展性较好！

3、单例模式（Singleton）

单例对象（Singleton）是一种经常使用的设计模式。在Java应用中，单例对象能保证在一个JVM中，该对象仅仅有一个实例存在。这种模式有几个优点：

1、某些类创建比較频繁，对于一些大型的对象，这是一笔非常大的系统开销。

2、省去了new操作符，减少了系统内存的使用频率，减轻GC压力。

3、有些类如交易所的核心交易引擎，控制着交易流程，假设该类能够创建多个的话，系统全然乱了。（比方一个军队出现了多个司令员同一时候指挥，肯定会乱成一团），所以仅仅有使用单例模式，才干保证核心交易server独立控制整个流程。

首先我们写一个简单的单例类：

这个类能够满足基本要求，可是，像这样毫无线程安全保护的类，假设我们把它放入多线程的环境下，肯定就会出现故障了，怎样解决？我们首先会想到对getInstance方法加synchronizedkeyword，例如以下：

可是，synchronizedkeyword锁住的是这个对象，这种使用方法，在性能上会有所下降，由于每次调用getInstance()，都要对对象上锁，其实，仅仅有在第一次创建对象的时候须要加锁，之后就不须要了，所以，这个地方须要改进。我们改成以下这个：

似乎攻克了之前提到的问题，将synchronizedkeyword加在了内部，也就是说当调用的时候是不须要加锁的，仅仅有在instance为null，并创建对象的时候才须要加锁，性能有一定的提升。可是，这种情况，还是有可能有问题的，看以下的情况：在Java指令中创建对象和赋值操作是分开进行的，也就是说instance = new Singleton();语句是分两步运行的。可是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，然后再去初始化这个Singleton实例。这样就可能出错了，我们以A、B两个线程为例：

a>A、B线程同一时候进入了第一个if推断

b>A首先进入synchronized块，因为instance为null，所以它运行instance = new Singleton();

c>因为JVM内部的优化机制，JVM先画出了一些分配给Singleton实例的空白内存，并赋值给instance成员（注意此时JVM没有開始初始化这个实例），然后A离开了synchronized块。

d>B进入synchronized块，因为instance此时不是null，因此它立即离开了synchronized块并将结果返回给调用该方法的程序。

e>此时B线程打算使用Singleton实例，却发现它没有被初始化，于是发生错误了。

所以程序还是有可能错误发生，事实上程序在执行过程是非常复杂的，从这点我们就能够看出，尤其是在写多线程环境下的程序更有难度，有挑战性。我们对该程序做进一步优化：

实际情况是，单例模式使用内部类来维护单例的实现，JVM内部的机制可以保证当一个类被载入的时候，这个类的载入过程是线程相互排斥的。这样当我们第一次调用getInstance的时候，JVM可以帮我们保证instance仅仅被创建一次，而且会保证把赋值给instance的内存初始化完成，这样我们就不用操心上面的问题。同一时候该方法也仅仅会在第一次调用的时候使用相互排斥机制，这样就攻克了低性能问题。这样我们临时总结一个完美的单例模式：

事实上说它完美，也不一定，假设在构造函数中抛出异常，实例将永远得不到创建，也会出错。所以说，十分完美的东西是没有的，我们仅仅能依据实际情况，选择最适合自己应用场景的实现方法。也有人这样实现：由于我们仅仅须要在创建类的时候进行同步，所以仅仅要将创建和getInstance()分开，单独为创建加synchronizedkeyword，也是能够的：

考虑性能的话，整个程序仅仅需创建一次实例，所以性能也不会有什么影响。

补充：採用"影子实例"的办法为单例对象的属性同步更新