Java设计模式

最新推荐文章于 2024-02-28 11:42:47 发布

huangshiqing28

最新推荐文章于 2024-02-28 11:42:47 发布

阅读量162

点赞数

本文链接：https://blog.csdn.net/huangshiqing28/article/details/102918719

版权

设计模式

1、java单例模式

摘要：
　本文首先概述了单例模式产生动机，揭示了单例模式的本质和应用场景。紧接着，我们给出了单例模式在单线程环境下的两种经典实现：饿汉式 和懒汉式，但是饿汉式是线程安全的，而懒汉式是非线程安全的。在多线程环境下，我们特别介绍了五种方式来在多线程环境下创建线程安全的单例，即分别使用synchronized方法、synchronized块、静态内部类、双重检查模式 和ThreadLocal 来实现懒汉式单例，并总结出实现效率高且线程安全的懒汉式单例所需要注意的事项。

一. 单例模式概述

单例模式（Singleton），也叫单子模式，是一种常用的设计模式。在应用这个模式时，单例对象的类必须保证只有一个实例存在。许多时候，整个系统只需要拥有一个的全局对象，这样有利于我们协调系统整体的行为。比如在某个服务器程序中，该服务器的配置信息存放在一个文件中，这些配置数据由一个单例对象统一读取，然后服务进程中的其他对象再通过这个单例对象获取这些配置信息，显然，这种方式简化了在复杂环境下的配置管理。

特别地，在计算机系统中，线程池、缓存、日志对象、对话框、打印机、显卡的驱动程序对象常被设计成单例。事实上，这些应用都或多或少具有资源管理器的功能。例如，每台计算机可以有若干个打印机，但只能有一个 Printer Spooler(单例) ，以避免两个打印作业同时输出到打印机中。再比如，每台计算机可以有若干通信端口，系统应当集中 (单例)管理这些通信端口，以避免一个通信端口同时被两个请求同时调用。总之，选择单例模式就是为了避免不一致状态，避免政出多头。

综上所述，单例模式就是为确保一个类只有一个实例，并为整个系统提供一个全局访问点的一种方法。

二. 单例模式及其单线程环境下的经典实现

单例模式应该是23种设计模式中最简单的一种模式了，下面我们从单例模式的定义、类型、结构和使用要素四个方面来介绍它。

1、单例模式理论基础

定义： 确保一个类只有一个实例，并为整个系统提供一个全局访问点 (向整个系统提供这个实例)。

类型： 创建型模式

结构：

特别地，为了更好地理解上面的类图，我们以此为契机，介绍一下类图的几个知识点：

类图分为三部分，依次是类名、属性、方法；
以<<开头和以>>结尾的为注释信息；
修饰符+代表public，-代表private，#代表protected，什么都没有代表包可见；
带下划线的属性或方法代表是静态的。

三要素：

私有的构造方法；
指向自己实例的私有静态引用；
以自己实例为返回值的静态的公有方法。

2、单线程环境下的两种经典实现

在介绍单线程环境中单例模式的两种经典实现之前，我们有必要先解释一下 立即加载 和延迟加载 两个概念。

· 立即加载： 在类加载初始化的时候就主动创建实例；

· 延迟加载： 等到真正使用的时候才去创建实例，不用时不去主动创建。

在单线程环境下，单例模式根据实例化对象时机的不同，有两种经典的实现：一种是 饿汉式单例(立即加载)，一种是 懒汉式单例(延迟加载)。**饿汉式单例在单例类被加载时候，就实例化一个对象并交给自己的引用；而懒汉式单例只有在真正使用的时候才会实例化一个对象并交给自己的引用。**代码示例分别如下：

饿汉式单例：
}

// 饿汉式单例
public class Singleton1 {

  // 指向自己实例的私有静态引用，主动创建
  private static Singleton1 singleton1 = new Singleton1();
   // 私有的构造方法
  private Singleton1(){}
     // 以自己实例为返回值的静态的公有方法，静态工厂方法
      public static Singleton1 getSingleton1(){
       return singleton1;
     }
    }

· 我们知道，类加载的方式是按需加载，且加载一次。。因此，在上述单例类被加载时，就会实例化一个对象并交给自己的引用，供系统使用；而且，由于这个类在整个生命周期中只会被加载一次，因此只会创建一个实例，即能够充分保证单例。

懒汉式单例：

 // 懒汉式单例

 public class Singleton2 {

   // 指向自己实例的私有静态引用
  private static Singleton2 singleton2;

   // 私有的构造方法

  private Singleton2(){}

       // 以自己实例为返回值的静态的公有方法，静态工厂方法
       public static Singleton2 getSingleton2(){
         // 被动创建，在真正需要使用时才去创建
         if (singleton2 == null) {
          singleton2 = new Singleton2();
         }
        return singleton2;
     }
    }

· 　我们从懒汉式单例可以看到，单例实例被延迟加载，即只有在真正使用的时候才会实例化一个对象并交给自己的引用。

总之，从速度和反应时间角度来讲，饿汉式（又称立即加载）要好一些；从资源利用效率上说，懒汉式（又称延迟加载）要好一些。

3、单例模式的优点

我们从单例模式的定义和实现，可以知道单例模式具有以下几个优点：

在内存中只有一个对象，节省内存空间；
避免频繁的创建销毁对象，可以提高性能；
避免对共享资源的多重占用，简化访问；
为整个系统提供一个全局访问点。

4、单例模式的使用场景

由于单例模式具有以上优点，并且形式上比较简单，所以是日常开发中用的比较多的一种设计模式，其核心在于为整个系统提供一个唯一的实例， 其应用场景包括但不仅限于以下几种：

有状态的工具类对象；
频繁访问数据库或文件的对象；

5、单例模式的注意事项

在使用单例模式时，我们必须使用单例类提供的公有工厂方法得到单例对象，而不应该使用反射来创建，否则将会实例化一个新对象。此外，在多线程环境下使用单例模式时，应特别注意线程安全问题，我在下文会重点讲到这一点。

三. 多线程环境下单例模式的实现

在单线程环境下，无论是饿汉式单例还是懒汉式单例，它们都能够正常工作。但是，在多线程环境下，情形就发生了变化：由于饿汉式单例天生就是线程安全的，可以直接用于多线程而不会出现问题；但懒汉式单例本身是非线程安全的，因此就会出现多个实例的情况，与单例模式的初衷是相背离的。下面我重点阐述以下几个问题：

· 为什么说饿汉式单例天生就是线程安全的？

· 传统的懒汉式单例为什么是非线程安全的？

· 怎么修改传统的懒汉式单例，使其线程变得安全？

· 线程安全的单例的实现还有哪些，怎么实现？

· 双重检查模式、Volatile关键字在单例模式中的应用

· ThreadLocal 在单例模式中的应用

特别地，为了能够更好的观察到单例模式的实现是否是线程安全的，我们提供了一个简单的测试程序来验证。该示例程序的判断原理是：

开启多个线程来分别获取单例，然后打印它们所获取到的单例的hashCode值。若它们获取的单例是相同的(该单例模式的实现是线程安全的)，那么它们的hashCode值一定完全一致；若它们的hashCode值不完全一致，那么获取的单例必定不是同一个，即该单例模式的实现不是线程安全的，是多例的。注意，相应输出结果附在每个单例模式实现示例后。

 public class Test {
   public static void main(String[] args) {
     Thread[] threads = new Thread[10];
    for (int i = 0; i < threads.length; i++) {
        threads[i] = new TestThread();
    }
    for (int i = 0; i < threads.length; i++) {
             threads[i].start();
         }
      }
    }
    
    class TestThread extends Thread {
      @Override
       public void run() {
       // 对于不同单例模式的实现，只需更改相应的单例类名及其公有静态工厂方法名即可
       int hash = Singleton5.getSingleton5().hashCode(); 
        System.out.println(hash);
      }
   }

1、为什么说饿汉式单例天生就是线程安全的？

 // 饿汉式单例
 public class Singleton1 {
   // 指向自己实例的私有静态引用，主动创建
   private static Singleton1 singleton1 = new Singleton1();
   // 私有的构造方法
   private Singleton1(){}
       // 以自己实例为返回值的静态的公有方法，静态工厂方法
       public static Singleton1 getSingleton1(){
         return singleton1;
       }

     } /*Output(完全一致):
        *1028355155*
        *1028355155*
        *1028355155*
        *1028355155*
        *1028355155*
       *1028355155*
        *1028355155*
        *1028355155*
        *1028355155*
        *1028355155*/

我们已经在上面提到，**类加载的方式是按需加载，且只加载一次。**因此，在上述单例类被加载时，就会实例化一个对象并交给自己的引用，供系统使用。换句话说，在线程访问单例对象之前就已经创建好了。再加上，由于一个类在整个生命周期中只会被加载一次，因此该单例类只会创建一个实例，也就是说，线程每次都只能也必定只可以拿到这个唯一的对象。因此就说，饿汉式单例天生就是线程安全的。

2、传统的懒汉式单例为什么是非线程安全的？

 // 传统懒汉式单例

 public class Singleton2 {

   // 指向自己实例的私有静态引用

   private static Singleton2 singleton2;

   // 私有的构造方法

   private Singleton2(){}
       // 以自己实例为返回值的静态的公有方法，静态工厂方法

      public static Singleton2 getSingleton2(){

        // 被动创建，在真正需要使用时才去创建
         if (singleton2 == null) {
          singleton2 = new Singleton2();
         }
         return singleton2;
       }
     } /*Output(不完全一致):
        1084284121
        2136955031
        2136955031
        1104499981
        298825033
        298825033
        2136955031
        482535999
        298825033
        2136955031*/

上面发生非线程安全的一个显著原因是，会有多个线程同时进入 if (singleton2 == null) {…} 语句块的情形发生。当这种这种情形发生后，该单例类就会创建出多个实例，违背单例模式的初衷。因此，传统的懒汉式单例是非线程安全的。

3、实现线程安全的懒汉式单例的几种正确姿势

1) 、同步延迟加载 — synchronized方法

 // 线程安全的懒汉式单例

 public class Singleton2 {
   private static Singleton2 singleton2; 
   private Singleton2(){}
   // 使用 synchronized修饰，临界资源的同步互斥访问

   public static synchronized Singleton2 getSingleton2(){
        if (singleton2 == null) {
           singleton2 = new Singleton2();
         }
         return singleton2;
       }

     }  /*Output(完全一致):
        *1104499981*
        *1104499981*
        *1104499981*
        *1104499981*
        *1104499981*
        *1104499981*
        *1104499981*
        *1104499981*
        *1104499981*
        *1104499981*/

该实现与上面传统懒汉式单例的实现唯一的差别就在于：是否使用 synchronized 修饰 getSingleton2()方法。 若使用，就保证了对临界资源的同步互斥访问，也就保证了单例。

从执行结果上来看，问题已经解决了，但是这种实现方式的运行效率会很低，因为同步块的作用域有点大，而且锁的粒度有点粗。同步方法效率低，那我们考虑使用同步代码块来实现。

2) 、同步延迟加载 — synchronized块

 // 线程安全的懒汉式单例

 public class Singleton2 {

   private static Singleton2 singleton2;

   private Singleton2(){}

   public static Singleton2 getSingleton2(){

         synchronized(Singleton2.class){ // 使用 synchronized 块，临界资源的同步互斥访问

          if (singleton2 == null) { 
             singleton2 = new Singleton2();
           }
         }
        return singleton2;
      }
     }   /*Output(完全一致):

        *16993205*
        *16993205*
        *16993205*
        *16993205*
        *16993205*
        *16993205*
        *16993205*
        *16993205*
        *16993205*
        *16993205*/

该实现与上面synchronized方法版本实现类似，此不赘述。从执行结果上来看，问题已经解决了，但是这种实现方式的运行效率仍然比较低，事实上，和使用synchronized方法的版本相比，基本没有任何效率上的提高。

3) 、同步延迟加载 — 使用内部类实现延迟加载

 // 线程安全的懒汉式单例

 public class Singleton5 { 

  // 私有内部类，按需加载，用时加载，也就是延迟加载
   private static class Holder {
    private static Singleton5 singleton5 = new Singleton5();
   }

  private Singleton5() { }      
       public static Singleton5 getSingleton5() {
        return Holder.singleton5;
      }
     }

        /*Output(完全一致):
         *482535999*
         *482535999*
         *482535999*
         *482535999*
         *482535999*
         *482535999*
         *482535999*
         *482535999*
         *482535999*
         *482535999*/

· 如上述代码所示，我们可以使用内部类实现线程安全的懒汉式单例，这种方式也是一种效率比较高的做法。至于其为什么是线程安全的，其与问题 “为什么说饿汉式单例天生就是线程安全的？” 相类似，此不赘述。

四. 单例模式与双重检查(Double-Check idiom)

使用双重检测同步延迟加载去创建单例的做法是一个非常优秀的做法，**其不但保证了单例，而且切实提高了程序运行效率。**对应的代码清单如下：

 // 线程安全的懒汉式单例

 public class Singleton3 {
   // 使用volatile关键字防止重排序，因为 new Instance()是一个非原子操作，可能创建一个不完整的实例

   private static volatile Singleton3 singleton3;
  
   private Singleton3() {

   }

       public static Singleton3 getSingleton3() {

         // Double-Check idiom

         if (singleton3 == null) {

           synchronized (Singleton3.class) {    // 1

             // 只需在第一次创建实例时才同步

             if (singleton3 == null) {    // 2
               singleton3 = new Singleton3();   // 3

            }
          }
         }

         return singleton3;
       }
     } /*Output(完全一致):
         *1104499981*
         *1104499981*
         *1104499981*
         *1104499981*
         *1104499981*
         *1104499981*
         *1104499981*
         *1104499981*
         *1104499981*
         *1104499981*/

如上述代码所示，为了在保证单例的前提下提高运行效率，我们需要对 singleton3 进行第二次检查，目的是避开过多的同步（因为这里的同步只需在第一次创建实例时才同步，一旦创建成功，以后获取实例时就不需要同步获取锁了）。这种做法无疑是优秀的，但是我们必须注意一点：
　
　必须使用volatile关键字修饰单例引用。

那么，如果上述的实现没有使用 volatile 修饰 singleton3，会导致什么情形发生呢？ 为解释该问题，我们分两步来阐述：

(1) 、当我们写了 new 操作，JVM 到底会发生什么？

首先，我们要明白的是： new Singleton3() 是一个非原子操作。 代码行singleton3 = new Singleton3(); 的执行过程可以形象地用如下3行伪代码来表示：

 memory = allocate();    //1:分配对象的内存空间

 ctorInstance(memory);    //2:初始化对象

 singleton3 = memory;    //3:使singleton3指向刚分配的内存地址

**但实际上，这个过程可能发生无序写入(指令重排序)，也就是说上面的3行指令可能会被重排序导致先执行第3行后执行第2行，**也就是说其真实执行顺序可能是下面这种：

 memory = allocate();    //1:分配对象的内存空间

 singleton3 = memory;    //3:使singleton3指向刚分配的内存地址

 ctorInstance(memory);    //2:初始化对象

这段伪代码演示的情况不仅是可能的，而且是一些 JIT 编译器上真实发生的现象。

(2) 、重排序情景再现
　
　了解 new 操作是非原子的并且可能发生重排序这一事实后，我们回过头看使用 Double-Check idiom 的同步延迟加载的实现：

我们需要重新考察上述清单中的 //3 行。此行代码创建了一个 Singleton 对象并初始化变量 singleton3 来引用此对象。这行代码存在的问题是，在 Singleton 构造函数体执行之前，变量 singleton3 可能提前成为非 null 的，即赋值语句在对象实例化之前调用，此时别的线程将得到的是一个不完整（未初始化）的对象，会导致系统崩溃。下面是程序可能的一组执行步骤：

1、线程 1 进入 getSingleton3() 方法；
　2、由于 singleton3 为 null，线程 1 在 //1 处进入 synchronized 块；
　3、同样由于 singleton3 为 null，线程 1 直接前进到 //3 处，但在构造函数执行之前，使实例成为非 null，并且该实例是未初始化的；
　4、线程 1 被线程 2 预占；
　5、线程 2 检查实例是否为 null。因为实例不为 null，线程 2 得到一个不完整（未初始化）的 Singleton 对象；
　6、线程 2 被线程 1 预占。
　7、线程 1 通过运行 Singleton3 对象的构造函数来完成对该对象的初始化。

显然，一旦我们的程序在执行过程中发生了上述情形，就会造成灾难性的后果，而这种安全隐患正是由于指令重排序的问题所导致的。让人兴奋地是，volatile 关键字正好可以完美解决了这个问题。也就是说，我们只需使用volatile关键字修饰单例引用就可以避免上述灾难。

五. 单例模式与 ThreadLocal

借助于 ThreadLocal，我们可以实现双重检查模式的变体。我们将临界资源线程局部化，具体到本例就是将双重检测的第一层检测条件 if (instance == null) 转换为线程局部范围内的操作。这里的 ThreadLocal 也只是用作标识而已，用来标识每个线程是否已访问过：如果访问过，则不再需要走同步块，这样就提高了一定的效率。对应的代码清单如下：

 // 线程安全的懒汉式单例

 public class Singleton4 {
  
  // ThreadLocal 线程局部变量
  private static ThreadLocal<Singleton4> threadLocal = new ThreadLocal<Singleton4>();
  private static Singleton4 singleton4 = null;  // 不需要是
   private Singleton4(){} 

       public static Singleton4 getSingleton4(){

        if (threadLocal.get() == null) {    // 第一次检查：该线程是否第一次访问
           createSingleton4();
         }
        return singleton4;
       }     
       public static void createSingleton4(){
         synchronized (Singleton4.class) {

           if (singleton4 == null) {     // 第二次检查：该单例是否被创建

             singleton4 = new Singleton4();  // 只执行一次
           }

        }

         threadLocal.set(singleton4);   // 将单例放入当前线程的局部变量中 

      }

     }   /*Output(完全一致):
         1028355155
         1028355155
         1028355155
         1028355155
         1028355155
         1028355155
         1028355155
         1028355155
         1028355155
         1028355155*/

借助于 ThreadLocal，我们也可以实现线程安全的懒汉式单例。但与直接双重检查模式使用，使用ThreadLocal的实现在效率上还不如双重检查锁定。

六. 小结

本文首先介绍了单例模式的定义和结构，并给出了其在单线程和多线程环境下的几种经典实现。特别地，我们知道，传统的饿汉式单例无论在单线程还是多线程环境下都是线程安全的，但是传统的懒汉式单例在多线程环境下是非线程安全的。 为此，我们特别介绍了五种方式来在多线程环境下创建线程安全的单例，包括：

使用synchronized方法实现懒汉式单例；
使用synchronized块实现懒汉式单例；
使用静态内部类实现懒汉式单例；
使用双重检查模式实现懒汉式单例；
使用ThreadLocal实现懒汉式单例；

当然，实现懒汉式单例还有其他方式。但是，这五种是比较经典的实现，也是我们应该掌握的几种实现方式。从这五种实现中，我们可以总结出，要想实现效率高的线程安全的单例，我们必须注意以下两点：

尽量减少同步块的作用域；
尽量使用细粒度的锁。

2、工厂模式

一句话总结：

· 简单工厂 ：一个工厂类，一个产品抽象类。

· 工厂方法 ：多个工厂类，一个产品抽象类。

· 抽象工厂 ：多个工厂类，多个产品抽象类。

简单工厂模式

简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。

简单工厂模式包含如下角色：

Factory：工厂角色
Product：抽象产品角色
ConcreteProduct：具体产品角色

优点：

工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。
客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。
通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

缺点：

由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。
系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

使用场景：
1、日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。
2、数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。
3、设计一个连接服务器的框架，需要三个协议，“POP3”、“IMAP”、“HTTP”，可以把这三个作为产品类，共同实现一个接口。

工厂方法模式

在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类

工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了面向对象的多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不负责哪一个产品类被实例化这种细节，这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。

工厂方法模式包含如下角色：

Product：抽象产品
ConcreteProduct：具体产品
Factory：抽象工厂
ConcreteFactory：具体工厂

优点：

在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。
基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，是因为所有的具体工厂类都具有同一抽象父类。
使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合“开闭原则”。

缺点：

在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。

应用场景：

客户端不需要知道它所创建的对象的类。例子中我们不知道每个图片加载器具体叫什么名，只知道创建它的工厂名就完成了床架过程。
客户端可以通过子类来指定创建对应的对象。

抽象工厂模式

抽象工厂模式(Abstract Factory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象创建型模式。

抽象工厂模式与工厂方法模式最大的区别在于，工厂方法模式针对的是一个产品等级结构，而抽象工厂模式则需要面对多个产品等级结构，一个工厂等级结构可以负责多个不同产品等级结构中的产品对象的创建。当一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象时，抽象工厂模式比工厂方法模式更为简单、有效率。

抽象工厂模式包含如下角色：

AbstractFactory：抽象工厂
ConcreteFactory：具体工厂
AbstractProduct：抽象产品
Product：具体产品

优点：

抽象工厂模式隔离了具体类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换一个具体工厂就变得相对容易。所有的具体工厂都实现了抽象工厂中定义的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。另外，应用抽象工厂模式可以实现高内聚低耦合的设计目的，因此抽象工厂模式得到了广泛的应用。
当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是一种非常实用的设计模式。
增加新的具体工厂和产品族很方便，无须修改已有系统，符合“开闭原则”。

缺点：

在添加新的产品对象时，难以扩展抽象工厂来生产新种类的产品，这是因为在抽象工厂角色中规定了所有可能被创建的产品集合，要支持新种类的产品就意味着要对该接口进行扩展，而这将涉及到对抽象工厂角色及其所有子类的修改，显然会带来较大的不便。
开闭原则的倾斜性（增加新的工厂和产品族容易，增加新的产品等级结构麻烦）。

适用环境：

一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是重要的。
系统中有多于一个的产品族，而每次只使用其中某一产品族。
属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。
系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。

了解：

设计模式的六大原则

1 、开闭原则（Open Close Principle）

开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

2 、里氏代换原则（Liskov Substitution Principle）

里氏代换原则是面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

3 、依赖倒转原则（Dependence Inversion Principle）

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

4 、接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

5 、迪米特法则，又称最少知道原则（Demeter Principle）

最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

6 、合成复用原则（Composite Reuse Principle）

合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。

设计模式的类型（23种）

1 创建型模式

这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

工厂模式（Factory Pattern）

抽象工厂模式（Abstract Factory Pattern）

单例模式（Singleton Pattern）

建造者模式（Builder Pattern）

原型模式（Prototype Pattern）

2 结构型模式

这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。

适配器模式（Adapter Pattern）

桥接模式（Bridge Pattern）

过滤器模式（Filter、Criteria Pattern）

组合模式（Composite Pattern）

装饰器模式（Decorator Pattern）

外观模式（Facade Pattern）

享元模式（Flyweight Pattern）

代理模式（Proxy Pattern）

3 行为型模式

这些设计模式特别关注对象之间的通信。

责任链模式（Chain of Responsibility Pattern）

命令模式（Command Pattern）

解释器模式（Interpreter Pattern）

迭代器模式（Iterator Pattern）

中介者模式（Mediator Pattern）

备忘录模式（Memento Pattern）

观察者模式（Observer Pattern）

状态模式（State Pattern）

空对象模式（Null Object Pattern）

策略模式（Strategy Pattern）

模板模式（Template Pattern）

访问者模式（Visitor Pattern）

4 J2EE 模式

这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。

MVC 模式（MVC Pattern）

业务代表模式（Business Delegate Pattern）

组合实体模式（Composite Entity Pattern）

数据访问对象模式（Data Access Object Pattern）

前端控制器模式（Front Controller Pattern）

拦截过滤器模式（Intercepting Filter Pattern）

服务定位器模式（Service Locator Pattern）

传输对象模式（Transfer Object Pattern）

Java 中几种常用设计模式

Java 中一般认为有23种设计模式，当然暂时不需要所有的都会，但是其中常见的几种设计模式应该去掌握。
总体来说设计模式分为三大类：
创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

1. 单例模式

所谓的单例设计指的是一个类只允许产生一个实例化对象。
最好理解的一种设计模式，分为懒汉式和饿汉式。

饿汉式：构造方法私有化，外部无法产生新的实例化对象，只能通过static方法取得实例化对象

class Singleton {
    /**
     * 在类的内部可以访问私有结构，所以可以在类的内部产生实例化对象
     */
    private static Singleton instance = new Singleton();
    /**
     * private 声明构造
     */
    private Singleton() {
 
    }
    /**
     * 返回对象实例
     */
    public static Singleton getInstance() {
        return instance;
    }
 
    public void print() {
        System.out.println("Hello Singleton...");
    }
}

懒汉式：当第一次去使用Singleton对象的时候才会为其产生实例化对象的操作

class Singleton {
 
    /**
     * 声明变量
     */
    private static volatile Singleton singleton = null;
 
    /**
     * 私有构造方法
     */
    private Singleton() {
 
    }
 
    /**
     * 提供对外方法
     * @return 
     */
    public static Singleton getInstance() {
        // 还未实例化
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
    public void print() {
        System.out.println("Hello World");
    }
}

当多个线程并发执行 getInstance 方法时，懒汉式会存在线程安全问题，所以用到了 synchronized 来实现线程的同步，当一个线程获得锁的时候其他线程就只能在外等待其执行完毕。而饿汉式则不存在线程安全的问题。

2. 工厂设计模式

工厂模式分为工厂方法模式和抽象工厂模式。

工厂方法模式

工厂方法模式：

工厂方法模式分为三种：普通工厂模式，就是建立一个工厂类，对实现了同一接口的一些类进行实例的创建。
多个工厂方法模式，是对普通工厂方法模式的改进，在普通工厂方法模式中，如果传递的字符串出错，则不能正确创建对象，而多个工厂方法模式是提供多个工厂方法，分别创建对象。
静态工厂方法模式，将上面的多个工厂方法模式里的方法置为静态的，不需要创建实例，直接调用即可。

1. 普通工厂模式

建立一个工厂类，对实现了同一接口的一些类进行实例的创建。

interface Sender {
    void Send();
}
 
class MailSender implements Sender {
 
    @Override
    public void Send() {
        System.out.println("This is mail sender...");
    }
}
 
class SmsSender implements Sender {
 
    @Override
    public void Send() {
        System.out.println("This is sms sender...");
    }
}
 
public class FactoryPattern {
    public static void main(String[] args) {
        Sender sender = produce("mail");
        sender.Send();
    }
    public static Sender produce(String str) {
        if ("mail".equals(str)) {
            return new MailSender();
        } else if ("sms".equals(str)) {
            return new SmsSender();
        } else {
            System.out.println("输入错误...");
            return null;
        }
    }
}

2. 多个工厂方法模式

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

interface Sender {
    void Send();
}
 
class MailSender implements Sender {
 
    @Override
    public void Send() {
        System.out.println("This is mail sender...");
    }
}
 
class SmsSender implements Sender {
 
    @Override
    public void Send() {
        System.out.println("This is sms sender...");
    }
}
 
class SendFactory {
    public Sender produceMail() {
        return new MailSender();
    }
 
    public Sender produceSms() {
        return new SmsSender();
    }
}
 
public class FactoryPattern {
    public static void main(String[] args) {
        SendFactory factory = new SendFactory();
        Sender sender = factory.produceMail();
        sender.Send();
    }
}

3. 静态工厂方法模式

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

interface Sender {
    void Send();
}
 
class MailSender implements Sender {
 
    @Override
    public void Send() {
        System.out.println("This is mail sender...");
    }
}
 
class SmsSender implements Sender {
 
    @Override
    public void Send() {
        System.out.println("This is sms sender...");
    }
}
 
class SendFactory {
    public static Sender produceMail() {
        return new MailSender();
    }
 
    public static Sender produceSms() {
        return new SmsSender();
    }
}
 
public class FactoryPattern {
    public static void main(String[] args) {
        Sender sender = SendFactory.produceMail();
        sender.Send();
    }
}

抽象工厂模式

工厂方法模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要扩展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，如何解决？
那么这就用到了抽象工厂模式，创建多个工厂类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。

interface Provider {
    Sender produce();
}
 
interface Sender {
    void Send();
}
 
class MailSender implements Sender {
 
    public void Send() {
        System.out.println("This is mail sender...");
    }
}
 
class SmsSender implements Sender {
 
    public void Send() {
        System.out.println("This is sms sender...");
    }
}
 
class SendMailFactory implements Provider {
 
    public Sender produce() {
        return new MailSender();
    }
}
 
class SendSmsFactory implements Provider {
 
    public Sender produce() {
        return new SmsSender();
    }
}
 
 
public class FactoryPattern {
    public static void main(String[] args) {
        Provider provider = new SendMailFactory();
        Sender sender = provider.produce();
        sender.Send();
    }
}

3. 建造者模式

工厂类模式提供的是创建单个类的模式，而建造者模式则是将各种产品集中起来管理，用来创建复合对象，所谓复合对象就是指某个类具有不同的属性。

import java.util.ArrayList;
import java.util.List;
 
/**
 * @Author: LiuWang
 * @Created: 2018/8/6 17:47
 */
 
abstract class Builder {
    /**
     * 第一步：装CPU
     */
   public abstract void buildCPU();
 
    /**
     * 第二步：装主板
     */
    public abstract void buildMainBoard();
 
    /**
     * 第三步：装硬盘
     */
    public abstract void buildHD();
 
    /**
     * 获得组装好的电脑
     * @return
     */
    public abstract Computer getComputer();
}
 
/**
 * 装机人员装机
 */
class Director {
    public void Construct(Builder builder) {
        builder.buildCPU();
        builder.buildMainBoard();
        builder.buildHD();
    }
}
 
/**
 * 具体的装机人员
 */
class ConcreteBuilder extends  Builder {
 
    Computer computer = new Computer();
 
    @Override
    public void buildCPU() {
        computer.Add("装CPU");
    }
 
    @Override
    public void buildMainBoard() {
        computer.Add("装主板");
    }
 
    @Override
    public void buildHD() {
        computer.Add("装硬盘");
    }
 
    @Override
    public Computer getComputer() {
        return computer;
    }
}
 
class Computer {
 
    /**
     * 电脑组件集合
     */
    private List<String> parts = new ArrayList<String>();
 
    public void Add(String part) {
        parts.add(part);
    }
 
    public void print() {
        for (int i = 0; i < parts.size(); i++) {
            System.out.println("组件:" + parts.get(i) + "装好了...");
        }
        System.out.println("电脑组装完毕...");
    }
}
 
public class BuilderPattern {
 
    public static void main(String[] args) {
        Director director = new Director();
        Builder builder = new ConcreteBuilder();
        director.Construct(builder);
        Computer computer = builder.getComputer();
        computer.print();
    }
}

4. 适配器设计模式

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

1. 类的适配器模式：

class Source {
    public void method1() {
        System.out.println("This is original method...");
    }
}
 
interface Targetable {
 
    /**
     * 与原类中的方法相同
     */
    public void method1();
 
    /**
     * 新类的方法
     */
    public void method2();
}
 
class Adapter extends Source implements Targetable {
 
    @Override
    public void method2() {
        System.out.println("This is the targetable method...");
    }
}
 
public class AdapterPattern {
    public static void main(String[] args) {
        Targetable targetable = new Adapter();
        targetable.method1();
        targetable.method2();
    }
}

2. 对象的适配器模式

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

class Source {
    public void method1() {
        System.out.println("This is original method...");
    }
}
 
interface Targetable {
 
    /**
     * 与原类中的方法相同
     */
    public void method1();
 
    /**
     * 新类的方法
     */
    public void method2();
}
 
class Wrapper implements Targetable {
 
    private Source source;
 
    public Wrapper(Source source) {
        super();
        this.source = source;
    }
 
    @Override
    public void method1() {
        source.method1();
    }
 
    @Override
    public void method2() {
        System.out.println("This is the targetable method...");
    }
}
 
public class AdapterPattern {
    public static void main(String[] args) {
        Source source = new Source();
        Targetable targetable = new Wrapper(source);
        targetable.method1();
        targetable.method2();
    }
}

3. 接口的适配器模式

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

/**
 * 定义端口接口，提供通信服务
 */
interface Port {
    /**
     * 远程SSH端口为22
     */
    void SSH();
 
    /**
     * 网络端口为80
     */
    void NET();
 
    /**
     * Tomcat容器端口为8080
     */
    void Tomcat();
 
    /**
     * MySQL数据库端口为3306
     */
    void MySQL();
}
 
/**
 * 定义抽象类实现端口接口，但是什么事情都不做
 */
abstract class Wrapper implements Port {
    @Override
    public void SSH() {
 
    }
 
    @Override
    public void NET() {
 
    }
 
    @Override
    public void Tomcat() {
 
    }
 
    @Override
    public void MySQL() {
 
    }
}
 
/**
 * 提供聊天服务
 * 需要网络功能
 */
class Chat extends Wrapper {
    @Override
    public void NET() {
        System.out.println("Hello World...");
    }
}
 
/**
 * 网站服务器
 * 需要Tomcat容器，Mysql数据库，网络服务，远程服务
 */
class Server extends Wrapper {
    @Override
    public void SSH() {
        System.out.println("Connect success...");
    }
 
    @Override
    public void NET() {
        System.out.println("WWW...");
    }
 
    @Override
    public void Tomcat() {
        System.out.println("Tomcat is running...");
    }
 
    @Override
    public void MySQL() {
        System.out.println("MySQL is running...");
    }
}
 
public class AdapterPattern {
 
    private static Port chatPort = new Chat();
    private static Port serverPort = new Server();
 
    public static void main(String[] args) {
        // 聊天服务
        chatPort.NET();
 
        // 服务器
        serverPort.SSH();
        serverPort.NET();
        serverPort.Tomcat();
        serverPort.MySQL();
    }
}

5. 装饰模式

顾名思义，装饰模式就是给一个对象增加一些新的功能，而且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。

interface Shape {
    void draw();
}
 
/**
 * 实现接口的实体类
 */
class Rectangle implements Shape {
 
    @Override
    public void draw() {
        System.out.println("Shape: Rectangle...");
    }
}
 
class Circle implements Shape {
 
    @Override
    public void draw() {
        System.out.println("Shape: Circle...");
    }
}
 
/**
 * 创建实现了 Shape 接口的抽象装饰类。
 */
abstract class ShapeDecorator implements Shape {
    protected Shape decoratedShape;
 
    public ShapeDecorator(Shape decoratedShape) {
        this.decoratedShape = decoratedShape;
    }
 
    @Override
    public void draw() {
        decoratedShape.draw();
    }
}
 
/**
 *  创建扩展自 ShapeDecorator 类的实体装饰类。
 */
class RedShapeDecorator extends ShapeDecorator {
 
    public RedShapeDecorator(Shape decoratedShape) {
        super(decoratedShape);
    }
 
    @Override
    public void draw() {
        decoratedShape.draw();
        setRedBorder(decoratedShape);
    }
 
    private void setRedBorder(Shape decoratedShape) {
        System.out.println("Border Color: Red");
    }
}
 
/**
 * 使用 RedShapeDecorator 来装饰 Shape 对象。
 */
public class DecoratorPattern {
    public static void main(String[] args) {
        Shape circle = new Circle();
        Shape redCircle = new RedShapeDecorator(new Circle());
        Shape redRectangle = new RedShapeDecorator(new Rectangle());
        System.out.println("Circle with normal border");
        circle.draw();
 
        System.out.println("\nCircle of red border");
        redCircle.draw();
 
        System.out.println("\nRectangle of red border");
        redRectangle.draw();
    }
}

6. 策略模式

策略模式定义了一系列算法，并将每个算法封装起来，使他们可以相互替换，且算法的变化不会影响到使用算法的客户。需要设计一个接口，为一系列实现类提供统一的方法，多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数。策略模式的决定权在用户，系统本身提供不同算法的实现，新增或者删除算法，对各种算法做封装。因此，策略模式多用在算法决策系统中，外部用户只需要决定用哪个算法即可。

/**
 * 抽象算法的策略类，定义所有支持的算法的公共接口
 */
abstract class Strategy {
    /**
     * 算法方法
     */
    public abstract void AlgorithmInterface();
}
 
/**
 * 具体算法A
 */
class ConcreteStrategyA extends Strategy {
    //算法A实现方法
    @Override
    public void AlgorithmInterface() {
        System.out.println("算法A的实现");
    }
}
 
/**
 * 具体算法B
 */
class ConcreteStrategyB extends Strategy {
    /**
     * 算法B实现方法
     */
    @Override
    public void AlgorithmInterface() {
        System.out.println("算法B的实现");
    }
}
 
/**
 * 具体算法C
 */
class ConcreteStrategyC extends Strategy {
    @Override
    public void AlgorithmInterface() {
        System.out.println("算法C的实现");
    }
}
 
/**
 * 上下文，维护一个对策略类对象的引用
 */
class Context {
    Strategy strategy;
 
    public Context(Strategy strategy) {
        this.strategy = strategy;
    }
 
    public void contextInterface(){
        strategy.AlgorithmInterface();
    }
}
 
/**
 * 客户端代码：实现不同的策略
 */
public class StrategyPattern {
    public static void main(String[] args) {
 
        Context context;
 
        context = new Context(new ConcreteStrategyA());
        context.contextInterface();
 
        context = new Context(new ConcreteStrategyB());
        context.contextInterface();
 
        context = new Context(new ConcreteStrategyC());
        context.contextInterface();
    }
}

7. 代理模式

代理模式指给一个对象提供一个代理对象，并由代理对象控制对原对象的引用。代理可以分为静态代理和动态代理。
通过代理模式，可以利用代理对象为被代理对象添加额外的功能，以此来拓展被代理对象的功能。可以用于计算某个方法执行时间，在某个方法执行前后记录日志等操作。

1. 静态代理

静态代理需要我们写出代理类和被代理类，而且一个代理类和一个被代理类一一对应。代理类和被代理类需要实现同一个接口，通过聚合使得代理对象中有被代理对象的引用，以此实现代理对象控制被代理对象的目的。

/**
 * 代理类和被代理类共同实现的接口
 */
interface IService {
 
    void service();
}
 
 
/**
 * 被代理类
 */
class Service implements IService{
 
    @Override
    public void service() {
        System.out.println("被代理对象执行相关操作");
    }
}
 
/**
 * 代理类
 */
class ProxyService implements IService{
    /**
     * 持有被代理对象的引用
     */
    private IService service;
 
    /**
     * 默认代理Service类
     */
    public ProxyService() {
        this.service = new Service();
    }
 
    /**
     * 也可以代理实现相同接口的其他类
     * @param service
     */
    public ProxyService(IService service) {
        this.service = service;
    }
 
    @Override
    public void service() {
        System.out.println("开始执行service()方法");
        service.service();
        System.out.println("service()方法执行完毕");
    }
}
 
 
//测试类
public class ProxyPattern {
 
    public static void main(String[] args) {
        IService service = new Service();
        //传入被代理类的对象
        ProxyService proxyService = new ProxyService(service);
        proxyService.service();
    }
}

2. 动态代理

JDK 1.3 之后，Java通过java.lang.reflect包中的三个类Proxy、InvocationHandler、Method来支持动态代理。动态代理常用于有若干个被代理的对象，且为每个被代理对象添加的功能是相同的（例如在每个方法运行前后记录日志）。

动态代理的代理类不需要我们编写，由Java自动产生代理类源代码并进行编译最后生成代理对象。
创建动态代理对象的步骤：

指明一系列的接口来创建一个代理对象
创建一个调用处理器（InvocationHandler）对象
将这个代理指定为某个其他对象的代理对象
在调用处理器的invoke（）方法中采取代理，一方面将调用传递给真实对象，另一方面执行各种需要的操作

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
 
/**
 * 代理类和被代理类共同实现的接口
 */
interface IService {
    void service();
}
 
class Service implements IService{
 
    @Override
    public void service() {
        System.out.println("被代理对象执行相关操作");
    }
}
 
class ServiceInvocationHandler implements InvocationHandler {
 
    /**
     * 被代理的对象
     */
    private Object srcObject;
 
    public ServiceInvocationHandler(Object srcObject) {
        this.srcObject = srcObject;
    }
 
    @Override
    public Object invoke(Object proxyObj, Method method, Object[] args) throws Throwable {
        System.out.println("开始执行"+method.getName()+"方法");
        //执行原对象的相关操作，容易忘记
        Object returnObj = method.invoke(srcObject,args);
        System.out.println(method.getName()+"方法执行完毕");
        return returnObj;
    }
}
 
public class ProxyPattern {
    public static void main(String[] args) {
        IService service = new Service();
        Class<? extends IService> clazz = service.getClass();
 
        IService proxyService = (IService) Proxy.newProxyInstance(clazz.getClassLoader(),
                                        clazz.getInterfaces(), new ServiceInvocationHandler(service));
        proxyService.service();
    }
}

huangshiqing28

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Java设计模式

设计模式1、java单例模式摘要：　本文首先概述了单例模式产生动机，揭示了单例模式的本质和应用场景。紧接着，我们给出了单例模式在单线程环境下的两种经典实现：饿汉式和懒汉式，但是饿汉式是线程安全的，而懒汉式是非线程安全的。在多线程环境下，我们特别介绍了五种方式来在多线程环境下创建线程安全的单例，即分别使用synchronized****方法、synchronized****块、静态内部类、双...
复制链接

扫一扫