当前位置： 移动技术网 > IT编程>软件设计>设计模式 > 设计模式总结

设计模式总结

2018年05月09日  | 移动技术网IT编程  | 我要评论

ref:https://www.cnblogs.com/geek6/p/3951677.html

　  https://www.cnblogs.com/maowang1991/archive/2013/04/15/3023236.html

　  https://www.cnblogs.com/tongkey/p/7170826.html

一、设计模式的分类

　　总体来说设计模式分为三大类：

　　创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

　　结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

　　行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

　　其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下：

　　

图1 设计模式之间的关系

二、Java的23中设计模式

A、创建模式

　　1、工厂方法模式（Factory Method）

　　定义：Define an interface for creating an object,but let subclasses decide which class to instantiate.Factory Method lets a class defer instantiation to subclasses.（定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。）

　　工厂方法模式分为三种：

　　1-1、普通工厂模式：就是建立一个工厂类，对实现了同一接口的一些类进行实例的创建。首先看下关系图：

 图2 普通工厂模式模式关系图　　

　　举例如下：（我们举一个发送邮件和短信的例子）

　　首先，创建二者的共同接口：

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

　　其次，创建实现类：

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

　　最后，建工厂类：

　　[java] 
    1. 　　public class SendFactory {
    2.    　　 public Sender produce(String type) {  
    3.        　　 if ("mail".equals(type)) {  
    4.             　　return new MailSender();  
    5.       　　  } else if ("sms".equals(type)) {  
    6.             　　return new SmsSender();  
    7.        　　 } else {  
    8.           　　  System.out.println("请输入正确的类型!");  
    9.            　　 return null;  
    10.        　　 }  
    11.    　　 }  
    12. 　　}  

　　我们来测试下：

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

　　输出：this is sms sender!

　　1-2、多个工厂方法模式：是对普通工厂方法模式的改进，在普通工厂方法模式中，如果传递的字符串出错，则不能正确创建对象，而多个工厂方法模式是提供多个工厂方法，分别创建对象。

图3  多个工厂方法模式关系图

　　将上面的代码做下修改，改动下SendFactory类就行，如下：

　　[java] public class SendFactory {  
   　　public Sender produceMail(){  
    1.         　　return new MailSender();  
    2.    　　 }
    3.  
    4.    　　 public Sender produceSms(){  
    5.        　　 return new SmsSender();  
    6.    　　 }  
    7. 　　}  

　　测试类如下：

　　[java] 
    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. 　　}  

　　输出：this is mailsender!

　　1-3、静态工厂方法模式：将上面的多个工厂方法模式里的方法置为静态的，不需要创建实例，直接调用即可。

　　[java] 
    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. 　　}  
　　[java] 
    1. 　　public class FactoryTest {  
    2. 　　  
    3.     　　public static void main(String[] args) {      
    4.        　　 Sender sender = SendFactory.produceMail();  
    5.        　　 sender.Send();  
    6.   　　  }  
    7. 　　}  

　　输出：this is mailsender!

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

　　使用场景：jdbc连接数据库，硬件访问，降低对象的产生和销毁。

　　2.抽象工厂模式（Abstract Factory Pattern）

　　定义：Provide an interface for creating families of related or dependent objects without specifying their concrete classes.（为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类。）
　　工厂方法模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，如何解决？就用到抽象工厂模式，创建多个工厂类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。因为抽象工厂不太好理解，我们先看看图，然后就和代码，就比较容易理解。
图4 抽象工厂模式关系图 

　　请看例子：

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

　　两个实现类：

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

　　两个工厂类：

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

　　再提供一个接口：

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

　　测试类：

　　[java] 
    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. 　　}  

　　其实这个模式的好处就是，如果你现在想增加一个功能：发及时信息，则只需做一个实现类，实现Sender接口，同时做一个工厂类，实现Provider接口，就OK了，无需去改动现成的代码。这样做，拓展性较好！　　

　　使用场景：一个对象族（或是一组没有任何关系的对象）都有相同的约束。涉及不同操作系统的时候，都可以考虑使用抽象工厂模式。

　　3.单例模式（Singleton Pattern）

　　定义：Ensure a class has only one instance, and provide a global point of access to it.（确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。）
　　单例对象（Singleton）是一种常用的设计模式。在Java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。这样的模式有几个好处：

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

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

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

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

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

　　这个类可以满足基本要求，但是，像这样毫无线程安全保护的类，如果我们把它放入多线程的环境下，肯定就会出现问题了，如何解决？我们首先会想到对getInstance方法加synchronized关键字，如下：

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

　　但是，synchronized关键字锁住的是这个对象，这样的用法，在性能上会有所下降，因为每次调用getInstance()，都要对对象上锁，事实上，只有在第一次创建对象的时候需要加锁，之后就不需要了，所以，这个地方需要改进。我们改成下面这个：

　　[java] 
    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.   　　  }  

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

  1. A、B线程同时进入了第一个if判断
  2. A首先进入synchronized块，由于instance为null，所以它执行instance = new Singleton();
  3. 由于JVM内部的优化机制，JVM先画出了一些分配给Singleton实例的空白内存，并赋值给instance成员（注意此时JVM没有开始初始化这个实例），然后A离开了synchronized块。
  4. B进入synchronized块，由于instance此时不是null，因此它马上离开了synchronized块并将结果返回给调用该方法的程序。
  5. 此时B线程打算使用Singleton实例，却发现它没有被初始化，于是错误发生了。

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

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

　　实际情况是，单例模式使用内部类来维护单例的实现，JVM内部的机制能够保证当一个类被加载的时候，这个类的加载过程是线程互斥的。这样当我们第一次调用getInstance的时候，JVM能够帮我们保证instance只被创建一次，并且会保证把赋值给instance的内存初始化完毕，这样我们就不用担心上面的问题。同时该方法也只会在第一次调用的时候使用互斥机制，这样就解决了低性能问题。这样我们暂时总结一个完美的单例模式：

　　[java] 
    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. 　　}  

　　其实说它完美，也不一定，如果在构造函数中抛出异常，实例将永远得不到创建，也会出错。所以说，十分完美的东西是没有的，我们只能根据实际情况，选择最适合自己应用场景的实现方法。也有人这样实现：因为我们只需要在创建类的时候进行同步，所以只要将创建和getInstance()分开，单独为创建加synchronized关键字，也是可以的：

　　[java] 
    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. 　　}  

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

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

　　[java] 
    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、单例模式理解起来简单，但是具体实现起来还是有一定的难度。

　　2、synchronized关键字锁定的是对象，在用的时候，一定要在恰当的地方使用（注意需要使用锁的对象和过程，可能有的时候并不是整个对象及整个过程都需要锁）。

　　到这儿，单例模式基本已经讲完了，结尾处，笔者突然想到另一个问题，就是采用类的静态方法，实现单例模式的效果，也是可行的，此处二者有什么不同？

　　首先，静态类不能实现接口。（从类的角度说是可以的，但是那样就破坏了静态了。因为接口中不允许有static修饰的方法，所以即使实现了也是非静态的）

　　其次，单例可以被延迟初始化，静态类一般在第一次加载是初始化。之所以延迟加载，是因为有些类比较庞大，所以延迟加载有助于提升性能。

　　再次，单例类可以被继承，他的方法可以被覆写。但是静态类内部方法都是static，无法被覆写。

　　最后一点，单例类比较灵活，毕竟从实现上只是一个普通的Java类，只要满足单例的基本需求，你可以在里面随心所欲的实现一些其它功能，但是静态类不行。从上面这些概括中，基本可以看出二者的区别，但是，从另一方面讲，我们上面最后实现的那个单例模式，内部就是用一个静态类来实现的，所以，二者有很大的关联，只是我们考虑问题的层面不同罢了。两种思想的结合，才能造就出完美的解决方案，就像HashMap采用数组+链表来实现一样，其实生活中很多事情都是这样，单用不同的方法来处理问题，总是有优点也有缺点，最完美的方法是，结合各个方法的优点，才能最好的解决问题！

　　使用场景：

　　1、要求生成唯一序列号的环境；

　　2、在整个项目中需要一个共享访问点或共享数据，例如一个Web页面上的计数器，可以不用把每次刷新都记录到数据库中，使用单例模式保持计数器的值，并确保是线程安全的；

　　3、创建一个对象需要消耗的资源过多，如要访问IO和数据库等资源；

　　4、需要定义大量的静态常量和静态方法（如工具类）的环境，可以采用单例模式（当然，也可以直接声明为static的方式）。

　　4.建造者模式（Builder Pattern）

　　定义：Separate the construction of a complex object from its representation so that the same construction process can create different representations.（将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。）
　　Builder模式是一步一步创建一个复杂的对象，它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们。用户不知道内部的具体构建细节。Builder模式是非常类似抽象工厂模式，细微的区别大概只有在反复使用中才能体会到。

图5 建造者模式关系图

　　1、上图是Strategy 模式的结构图，让我们可以进行更方便的描述；

　　2、Builder：为创建一个Product对象的各个部件指定抽象接口。

　　3、ConcreteBuilder：实现Builder的接口以构造和装配该产品的各个部件，定义并明确它所创建的表示，提供一个检索产品的接口

　　4、Director：构造一个使用Builder接口的对象。

　　5、Product：表示被构造的复杂对象。ConcreateBuilder创建该产品的内部表示并定义它的装配过程。

　　为何使用

　　是为了将构建复杂对象的过程和它的部件解耦。注意：是解耦过程和部件。
　　因为一个复杂的对象，不但有很多大量组成部分，如汽车，有很多部件：车轮、方向盘、发动机，还有各种小零件等等，部件很多，但远不止这些，如何将这些部件装配成一辆汽车，这个装配过程也很复杂(需要很好的组装技术)，Builder模式就是为了将部件和组装过程分开。

　　如何使用

　　首先假设一个复杂对象是由多个部件组成的，Builder模式是把复杂对象的创建和部件的创建分别开来，分别用Builder类和Director类来表示。

　　首先，需要一个接口，它定义如何创建复杂对象的各个部件：

　　public interface Builder {
　  　　//创建部件A　　比如创建汽车车轮void buildPartA();
　  　　//创建部件B 比如创建汽车方向盘void buildPartB();
　  　　//创建部件C 比如创建汽车发动机void buildPartC();
　  　　//返回最后组装成品结果 (返回最后装配好的汽车)
　  　　//成品的组装过程不在这里进行,而是转移到下面的Director类中进行.
　 　　 //从而实现了解耦过程和部件
   　　 Product getResult();
　　}

　　用Director构建最后的复杂对象，而在上面Builder接口中封装的是如何创建一个个部件(复杂对象是由这些部件组成的)，也就是说Director的内容是如何将部件最后组装成成品：

　　public class Director {
    　　private Builder builder;
    　　public Director( Builder builder ) {
        　　this.builder = builder;
　  　　}
　  　　// 将部件partA partB partC最后组成复杂对象
　  　　//这里是将车轮 方向盘和发动机组装成汽车的过程
    　　public void construct() {
        　　builder.buildPartA();
        　　builder.buildPartB();
        　　builder.buildPartC();
    　　}
　　}

　　Builder的具体实现ConcreteBuilder：

　　1、通过具体完成接口Builder来构建或装配产品的部件；

　　2、定义并明确它所要创建的是什么具体东西；

　　3、提供一个可以重新获取产品的接口。

　　public class ConcreteBuilder implements Builder {
　　　Part partA, partB, partC;
　　　public void buildPartA() {
　　　　//这里是具体如何构建
　　　}
　　　public void buildPartB() {
　　　　//这里是具体如何构建
　　　}
　　　public void buildPartC() {
　　　　//这里是具体如何构建
　　　}
　　　public Product getResult() {
　　　　//返回最后组装成品结果
　　　}
　　}

　　复杂对象：产品Product：

　　public interface Product { }

　　复杂对象的部件：

　　public interface Part { }

　　我们看看如何调用Builder模式:

　　ConcreteBuilder builder = new ConcreteBuilder();
　　Director director = new Director( builder );
　　director.construct();
　　Product product = builder.getResult();

　　Builder模式的应用

　　在Java实际使用中，我们经常用到"池"(Pool)的概念，当资源提供者无法提供足够的资源，并且这些资源需要被很多用户反复共享时，就需要使用池。"池"实际是一段内存，当池中有一些复杂的资源的"断肢"(比如数据库的连接池，也许有时一个连接会中断)，如果循环再利用这些"断肢"，将提高内存使用效率，提高池的性能。修改Builder模式中Director类使之能诊断"断肢"断在哪个部件上，再修复这个部件。

​　　建造者模式与工厂模式的不同：

　　1、建造者模式最主要的功能是基本方法的调用顺序安排，这些基本方法已经实现了，顺序不同产生的对象也不同；

　　2、工厂方法则重点是创建，创建零件是它的主要职责，组装顺序则不是它关心的。

　　5.原型模式（Prototype Pattern）

　　定义：Specify the kinds of objects to create using a prototypical instance,and create new objects by copying this prototype.（用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。）
　　原型模式虽然是创建型的模式，但是与工程模式没有关系，从名字即可看出，该模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。本小结会通过对象的复制，进行讲解。在Java中，复制对象是通过clone()实现的，先创建一个原型类：
　　[java] 
    1. 　　public class Prototype implements Cloneable {  
    2. 　　  
    3.    　　 public Object clone() throws CloneNotSupportedException {  
    4.        　　 Prototype proto = (Prototype) super.clone();  
    5.         　　return proto;  
    6.     　　}  
    7. 　　}  

　　很简单，一个原型类，只需要实现Cloneable接口，覆写clone方法，此处clone方法可以改成任意的名称，因为Cloneable接口是个空接口，你可以任意定义实现类的方法名，如cloneA或者cloneB，因为此处的重点是super.clone()这句话，super.clone()调用的是Object的clone()方法，而在Object类中，clone()是native的，关于解读Java中本地方法的调用，此处不再深究。在这儿，我将结合对象的浅复制和深复制来说一下，首先需要了解对象深、浅复制的概念：

　　浅复制：将一个对象复制后，基本数据类型的变量都会重新创建，而引用类型，指向的还是原对象所指向的。

　　深复制：将一个对象复制后，不论是基本数据类型还有引用类型，都是重新创建的。简单来说，就是深复制进行了完全彻底的复制，而浅复制不彻底。

　　此处，写一个深浅复制的例子：

　　[java] 
    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. 　　}   
　　要实现深复制，需要采用流的形式读入当前对象的二进制输入，再写出二进制数据对应的对象。

　　原型模式实际上就是实现Cloneable接口，重写clone（）方法。

　　使用原型模式的优点：

　　1、性能优良

　　原型模式是在内存二进制流的拷贝，要比直接new一个对象性能好很多，特别是要在一个循环体内产生大量的对象时，原型模式可以更好地体现其优点。

　　2、逃避构造函数的约束

　　这既是它的优点也是缺点，直接在内存中拷贝，构造函数是不会执行的（参见13.4节）。

　　使用场景：

　　1、资源优化场景

　　类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。

　　2、性能和安全要求的场景

　　通过new产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。

　　3、一个对象多个修改者的场景

　　一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。

B、结构模式

　　6、适配器模式（Adapter Pattern）

　　定义：Convert the interface of a class into another interface clients expect.Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.（将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。）

　　适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。

　　6-1、类的适配器模式

图6 类的适配器模式关系图 

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

　　[java] 
    1. 　　public class Source {  
    2. 　　  
    3.     　　public void method1() {  
    4.        　　 System.out.println("this is original method!");  
    5.    　　 }  
    6. 　　}  
　　[java] 
    1. 　　public interface Targetable {  
    2. 　　  
    3.    　　 /* 与原类中的方法相同 */  
    4.    　　 public void method1();  
    5.   　　
    6.   　　  /* 新类的方法 */  
    7.   　　  public void method2();  
    8. 　　}  
　　[java] 
    1. 　　public class Adapter extends Source implements Targetable {  
    2. 　　  
    3.    　　 @Override  
    4.     　　public void method2() {  
    5.        　　 System.out.println("this is the targetable method!");  
    6.     　　}  
    7. 　　}  

　　Adapter类继承Source类，实现Targetable接口，下面是测试类：

　　[java] 
    1. 　　public class AdapterTest {  
    2.   　　
    3.     　　public static void main(String[] args) {  
    4.        　　 Targetable target = new Adapter();  
    5.        　　 target.method1();  
    6.       　　  target.method2();  
    7.    　　 }  
    8. 　　}  

　　输出：

　　this is original method!
　　this is the targetable method!

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

　　6-2、对象的适配器模式

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

图7 对象的适配器模式关系图

　　只需要修改Adapter类的源码即可：

　　[java] 
    1. 　　public class Wrapper implements Targetable {  
    2.   　　
    3.    　　 private Source source;  
    4.   　　    
    5.    　　 public Wrapper(Source source){  
    6.     　　    super();  
    7.        　　 this.source = source;  
    8.   　　  }  
    9.    　　 @Override  
    10.     　　public void method2() {  
    11.       　　  System.out.println("this is the targetable method!");  
    12.    　　 }  
    13.  　　   @Override  
    14.  　　   public void method1() {  
    15.    　　     source.method1();  
    16.    　　 }  
    17. 　　}  

　　测试类：

　　[java] 
    1. 　　public class AdapterTest {  
    2. 　　  
    3.  　　   public static void main(String[] args) {  
    4.      　　   Source source = new Source();  
    5.       　　  Targetable target = new Wrapper(source);  
    6.       　　  target.method1();  
    7.       　　  target.method2();  
    8.    　　 }  
    9. 　　}  

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

　　6-3、接口的适配器模式

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

 

图8 接口的适配器模式关系图

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

　　[java] 
    1. 　　public interface Sourceable {  
    2. 　　      
    3.   　　  public void method1();  
    4.   　　  public void method2();  
    5. 　　}  

　　抽象类Wrapper2：

　　[java] 
    1. 　　public abstract class Wrapper2 implements Sourceable{  
    2. 　　      
    3.    　　 public void method1(){}  
    4.    　　 public void method2(){}  
    5. 　　}  
　　[java] 
    1. 　　public

您可能感兴趣的文章:

如对本文有疑问， 点击进行留言回复！！

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网