设计模式总结

最新推荐文章于 2025-03-21 13:51:02 发布

一行两行

最新推荐文章于 2025-03-21 13:51:02 发布

阅读量217

点赞数

分类专栏：设计模式文章标签：设计模式

本文链接：https://blog.youkuaiyun.com/seebetpro/article/details/98107821

版权

设计模式专栏收录该内容

1 篇文章

订阅专栏

一.单例模式七种写法：

1.第一种（懒汉，线程不安全）：

public class Singleton {  
    private static Singleton instance;  
    private Singleton (){}  
  
    public static Singleton getInstance() {  
    if (instance == null) {  
        instance = new Singleton();  
    }  
    return instance;  
    }  
}

这种写法lazy loading很明显，但是致命的是在多线程不能正常工作。

2.第二种（懒汉，线程安全）：

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

这种写法能够在多线程中很好的工作，而且看起来它也具备很好的lazy loading，但是，遗憾的是，效率很低，99%情况下不需要同步。

3.第三种（饿汉）：

public class Singleton {  
    private static Singleton instance = new Singleton();  
    private Singleton (){}  
    public static Singleton getInstance() {  
    return instance;  
    }  
}

这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用getInstance方法，但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化instance显然没有达到lazy loading的效果。

4.第四种（饿汉，变种）：

public class Singleton {  
    private Singleton instance = null;  
    static {  
    instance = new Singleton();  
    }  
    private Singleton (){}  
    public static Singleton getInstance() {  
    return this.instance;  
    }  
}

表面上看起来差别挺大，其实更第三种方式差不多，都是在类初始化即实例化instance。

5.第五种（静态内部类）：

public class Singleton {  
    private static class SingletonHolder {  
    private static final Singleton INSTANCE = new Singleton();  
    }  
    private Singleton (){}  
    public static final Singleton getInstance() {  
    return SingletonHolder.INSTANCE;  
    }  
}

这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程，它跟第三种和第四种方式不同的是（很细微的差别）：第三种和第四种方式是只要Singleton类被装载了，那么instance就会被实例化（没有达到lazy loading效果），而这种方式是Singleton类被装载了，instance不一定被初始化。因为SingletonHolder类没有被主动使用，只有显示通过调用getInstance方法时，才会显示装载SingletonHolder类，从而实例化instance。想象一下，如果实例化instance很消耗资源，我想让他延迟加载，另外一方面，我不希望在Singleton类加载时就实例化，因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化instance显然是不合适的。这个时候，这种方式相比第三和第四种方式就显得很合理。

6.第六种（枚举）：

public enum Singleton {  
    INSTANCE;  
    public void whateverMethod() {  
    }  
}

这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象，可谓是很坚强的壁垒啊，不过，个人认为由于1.5中才加入enum特性，用这种方式写不免让人感觉生疏，在实际工作中，我也很少看见有人这么写过。

7.第七种（双重校验锁）：

public class Singleton {  
    private volatile static Singleton singleton;  
    private Singleton (){}  
    public static Singleton getSingleton() {  
    if (singleton == null) {  
        synchronized (Singleton.class) {  
        if (singleton == null) {  
            singleton = new Singleton();  
        }  
        }  
    }  
    return singleton;  
    }  
}

这个是第二种方式的升级版，俗称双重检查锁定，详细介绍请查看：http://www.ibm.com/developerworks/cn/java/j-dcl.html

在JDK1.5之后，双重检查锁定才能够正常达到单例效果。

总结

有两个问题需要注意：

1.如果单例由不同的类装载器装入，那便有可能存在多个单例类的实例。假定不是远端存取，例如一些servlet容器对每个servlet使用完全不同的类装载器，这样的话如果有两个servlet访问一个单例类，它们就都会有各自的实例。

2.如果Singleton实现了java.io.Serializable接口，那么这个类的实例就可能被序列化和复原。不管怎样，如果你序列化一个单例类的对象，接下来复原多个那个对象，那你就会有多个单例类的实例。

对第一个问题修复的办法是：

private static Class getClass(String classname)      
                                         throws ClassNotFoundException {     
      ClassLoader classLoader = Thread.currentThread().getContextClassLoader();     
      
      if(classLoader == null)     
         classLoader = Singleton.class.getClassLoader();     
      
      return (classLoader.loadClass(classname));     
   }     
}

对第二个问题修复的办法是：

public class Singleton implements java.io.Serializable {     
   public static Singleton INSTANCE = new Singleton();     
      
   protected Singleton() {     
        
   }     
   private Object readResolve() {     
            return INSTANCE;     
      }    
}

对我来说，我比较喜欢第三种和第五种方式，简单易懂，而且在JVM层实现了线程安全（如果不是多个类加载器环境），一般的情况下，我会使用第三种方式，只有在要明确实现lazy loading效果时才会使用第五种方式，另外，如果涉及到反序列化创建对象时我会试着使用枚举的方式来实现单例，不过，我一直会保证我的程序是线程安全的，而且我永远不会使用第一种和第二种方式，如果有其他特殊的需求，我可能会使用第七种方式，毕竟，JDK1.5已经没有双重检查锁定的问题了。

二.简单工厂模式

简单工厂模式解释：

简单工厂模式（Simple Factory Pattern）属于类的创新型模式，又叫静态工厂方法模式（Static FactoryMethod Pattern）,是通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

简单工厂模式的UML图：

简单工厂模式中包含的角色及其相应的职责如下：

工厂角色（Creator）：这是简单工厂模式的核心，由它负责创建所有的类的内部逻辑。当然工厂类必须能够被外界调用，创建所需要的产品对象。

抽象（Product）产品角色：简单工厂模式所创建的所有对象的父类，注意，这里的父类可以是接口也可以是抽象类，它负责描述所有实例所共有的公共接口。

具体产品（Concrete Product）角色：简单工厂所创建的具体实例对象，这些具体的产品往往都拥有共同的父类。

简单工厂模式深入分析：

简单工厂模式解决的问题是如何去实例化一个合适的对象。

简单工厂模式的核心思想就是：有一个专门的类来负责创建实例的过程。

具体来说，把产品看着是一系列的类的集合，这些类是由某个抽象类或者接口派生出来的一个对象树。而工厂类用来产生一个合适的对象来满足客户的要求。

如果简单工厂模式所涉及到的具体产品之间没有共同的逻辑，那么我们就可以使用接口来扮演抽象产品的角色；如果具体产品之间有功能的逻辑或，我们就必须把这些共同的东西提取出来，放在一个抽象类中，然后让具体产品继承抽象类。为实现更好复用的目的，共同的东西总是应该抽象出来的。

在实际的的使用中，抽闲产品和具体产品之间往往是多层次的产品结构，如下图所示：

简单工厂模式使用场景分析及代码实现：

GG请自己的女朋友和众多美女吃饭，但是GG自己是不会做饭的或者做的饭很不好，这说明GG不用自己去创建各种食物的对象；各个美女都有各自的爱好，到麦当劳后她们喜欢吃什么直接去点就行了，麦当劳就是生产各种食物的工厂，这时候GG不用自己动手，也可以请这么多美女吃饭，所要做的就是买单O(∩_∩)O哈哈~,其UML图如下所示：

实现代码如下：

新建立一个食物的接口：

// 产品的抽象接口
public interface Food {
    // 获得相应的食物
    public void get();
}

接下来建立具体的产品：麦香鸡和薯条

// 麦香鸡对抽象产品接口的实现
public class McChicken implements Food{
    // 获取一份麦香鸡
    public void get(){
        System.out.println("我要一份麦香鸡");
    }
}

// 薯条对抽象产品接口的实现
public class Chips implements Food{
    // 获取一份薯条
    public void get(){
        System.out.println("我要一份薯条");
    }
}

现在建立一个食物加工工厂：

public class FoodFactory {
    public static Food getFood(String type) throws InstantiationException, IllegalAccessException, ClassNotFoundException {
        if(type.equalsIgnoreCase("mcchicken")) {
            return McChicken.class.newInstance();
        } else if(type.equalsIgnoreCase("chips")) {
            return Chips.class.newInstance();
        } else {
            System.out.println("哎呀！找不到相应的实例化类啦！");
            return null;
        }
    }
}

最后我们建立测试客户端：

// 测试客户端
public class SimpleFactoryTest {
    public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {
        //实例化各种食物
        Food mcChicken = FoodFactory.getFood("McChicken");
        Food chips = FoodFactory.getFood("Chips");
        Food eggs = FoodFactory.getFood("Eggs");

        //获取食物
        if(mcChicken!=null){
            mcChicken.get();
        }

        if(chips!=null){
            chips.get();
        }

        if(eggs!=null){
            eggs.get();
        }
    }
}

输出的结果如下：

哎呀！找不到相应的实例化类啦！
我要一份麦香鸡
我要一份薯条

简单工厂模式的优缺点分析：

优点：工厂类是整个模式的关键所在。它包含必要的判断逻辑，能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。

缺点：由于工厂类集中了所有实例的创建逻辑，这就直接导致一旦这个工厂出了问题，所有的客户端都会受到牵连；而且由于简单工厂模式的产品室基于一个共同的抽象类或者接口，这样一来，但产品的种类增加的时候，即有不同的产品接口或者抽象类的时候，工厂类就需要判断何时创建何种种类的产品，这就和创建何种种类产品的产品相互混淆在了一起，违背了单一职责，导致系统丧失灵活性和可维护性。而且更重要的是，简单工厂模式违背了“开放封闭原则”，就是违背了“系统对扩展开放，对修改关闭”的原则，因为当我新增加一个产品的时候必须修改工厂类，相应的工厂类就需要重新编译一遍。

总结一下：简单工厂模式分离产品的创建者和消费者，有利于软件系统结构的优化；但是由于一切逻辑都集中在一个工厂类中，导致了没有很高的内聚性，同时也违背了“开放封闭原则”。另外，简单工厂模式的方法一般都是静态的，而静态工厂方法是无法让子类继承的，因此，简单工厂模式无法形成基于基类的继承树结构。

简单工厂模式的实际应用简介：

作为一个最基本和最简单的设计模式，简单工厂模式却有很非常广泛的应用，我们这里以Java中的JDBC操作数据库为例来说明。

JDBC是SUN公司提供的一套数据库编程接口API，它利用Java语言提供简单、一致的方式来访问各种关系型数据库。Java程序通过JDBC可以执行SQL语句，对获取的数据进行处理，并将变化了的数据存回数据库，因此，JDBC是Java应用程序与各种关系数据进行对话的一种机制。用JDBC进行数据库访问时，要使用数据库厂商提供的驱动程序接口与数据库管理系统进行数据交互。

客户端要使用使用数据时，只需要和工厂进行交互即可，这就导致操作步骤得到极大的简化，操作步骤按照顺序依次为：注册并加载数据库驱动，一般使用Class.forName();创建与数据库的链接Connection对象；创建SQL语句对象preparedStatement(sql)；提交SQL语句，根据实际情况使用executeQuery()或者executeUpdate()；显示相应的结果；关闭数据库。

三.建造者模式（Builder）

一个人活到70岁以上，都会经历这样的几个阶段：婴儿，少年，青年，中年，老年。并且每个人在各个阶段肯定是不一样的呀，我觉得可以说世界上不存在两个人在人生的这5个阶段的生活完全一样，但是活到70岁以上的人，都经历了这几个阶段是肯定的。实际上这是一个比较经典的建造者模式的例子了。

1.初识建造者模式

建造者模式实际上是常用的设计模式。顾名思义，builder的意思是建造者或者建筑工人，谈到建造自然会想到楼房。楼房是千差万别的，楼房的外形、层数、内部房间的数量、房间的装饰等等都不一样，但是对于建造者来说，抽象出来的建筑流程是确定的，往往建筑一座楼房包括下面的步骤：（1）打桩，建立基础（2）建立框架等。

建造者模式的本质和建造楼房是一致的：即流程不变，但每个流程实现的具体细节则是经常变化的。建造者模式的好处就是保证了流程不会变化，流程即不会增加、也不会遗漏或者产生流程次序错误，这是非常重要的。我们熟知的楼歪歪事件，官方的解释就是由于先建立楼房后，再建设停车场造成的，这是典型的建造次序错乱。（看来这些人儿不知道建造者模式啊！！！）

我生活的地方有一个菜叫“锅包肉”。基本每个餐馆都有，但是每个餐馆的味道都不一样，原因是什么呢？因为这道菜的作法没有形成标准呗！每个人的作法都不一样，所以味道就不一样了。这实际上通过“建造者模式”让每个馆子的“锅包肉”都一样。同样的KFC做出来的东西，不论是全国哪家店做出来就都一个味，因为KFC内部有很严格的规定，做巨无霸有做巨无霸的流程，必须严格遵守，这样做出来的东西当然一致了。KFC就是采用了建造者模式！！

下面看看建造者模式的定义：

建造者模式：是将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

建造者模式通常包括下面几个角色：

1. builder：给出一个抽象接口，以规范产品对象的各个组成成分的建造。这个接口规定要实现复杂对象的哪些部分的创建，并不涉及具体的对象部件的创建。

2. ConcreteBuilder：实现Builder接口，针对不同的商业逻辑，具体化复杂对象的各部分的创建。在建造过程完成后，提供产品的实例。

3. Director：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。

4. Product：要创建的复杂对象。

按照惯例，还是给出建造者模式的结构图：

2.一个建造者模式例子实现

　　不妨就实现《大话设计模式》上的建造小人的例子吧！！在游戏开发中建造小人是经常的事了，要求是：小人必须包括，头，身体，手和脚。现在系统要包括的分为胖人和瘦人。写出建造者模式的代码如下：

//Product类
public class Product {
    List<String> parts = new ArrayList<>();

    public void add(String part) {
        parts.add(part);
    }

    public void show() {
        for (int i = 0; i < parts.size(); i++) {
            System.out.println(parts.get(i));
        }
    }
}

//抽象builder类
public interface Builder {
    void BuildHead();

    void BuildBody();

    void BuildHand();

    void BuildFeet();

    Product GetResult();
}

//具体胖人创建类
public class FatPersonBuilder implements Builder {
    private Product mProduct = new Product();

    @Override
    public void BuildHead() {
        mProduct.add("胖人头");//创建胖人的头
    }

    @Override
    public void BuildBody() {
        mProduct.add("胖人身体");//创建胖人的身体
    }

    @Override
    public void BuildHand() {
        mProduct.add("胖人手");//创建胖人的手
    }

    @Override
    public void BuildFeet() {
        mProduct.add("胖人脚");//创建胖人的脚
    }

    @Override
    public Product GetResult() {
        return mProduct;
    }
}

//具体瘦人创建类
public class ThinPersonBuilder implements Builder {

    private Product mProduct = new Product();

    @Override
    public void BuildHead() {
        mProduct.add("瘦人头");//创建瘦人的头
    }

    @Override
    public void BuildBody() {
        mProduct.add("瘦人身体");//创建瘦人的身体
    }

    @Override
    public void BuildHand() {
        mProduct.add("瘦人手");//创建瘦人的手
    }

    @Override
    public void BuildFeet() {
        mProduct.add("瘦人脚");//创建瘦人的脚
    }

    @Override
    public Product GetResult() {
        return mProduct;
    }
}

//指导建造类，控制统一流程
public class Director {

    public void Directe(Builder builder) {
        builder.BuildHead();
        builder.BuildBody();
        builder.BuildHand();
        builder.BuildFeet();
    }
}

public class Test {

    public static void main(String[] args) {
        //控制建造过程顺序
        Director director = new Director();
        //创建实体
        Builder b1 = new FatPersonBuilder();
        Builder b2 = new ThinPersonBuilder();
        //开始建造
        director.Directe(b1);
        Product p = b1.GetResult();
        p.show();
    }
}

看过上面代码发现使用建造者模式有什么好处了吗？上面的例子，通过建造者模式，使得建造过程通过Director类的Construct函数固定了，即建造过程不会变，也就是满足上面要求中红色字体的“必须包括”。但是具体的头，身体，手脚这些身体的各个部分会变化，基类Builder中将各种Build函数定义为抽象方法，必须在子类中实现。这样不仅仅使得建造小人的过程不变，而且很利于系统的扩展，一旦出现其他种类的人根本不需要改动之前的FatPersonBuider，ThinPersonBuilder，Director，Product等类，只需要新添加新的类。符合OCP原则。

到这里不知道大家有没有这样的疑问，建造者模式和工厂模式非常相似啊，确实是非常的相似，建造者模式注重零部件的组装过程，而工厂方法模式更注重零部件的创建过程。两者也有结合使用：比如众神造人，女娲利用建造者模式负责把灵魂、耳目、手臂等组合成一个完整的人，而皇帝、桑林等人各自利用工厂方法模式创造出灵魂，耳目，手臂等。女娲不必考虑灵魂、耳目、手臂是什么样子的，怎么创造出来的，这就成为了一个由建造者模式和工厂方法模式组合而成的系统。

3.使用建造者模式的场合和好处

使用建造者模式的好处：

1.使用建造者模式可以使客户端不必知道产品内部组成的细节。

2.具体的建造者类之间是相互独立的，对系统的扩展非常有利。

3.由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。

使用建造模式的场合：

1.创建一些复杂的对象时，这些对象的内部组成构件间的建造顺序是稳定的，但是对象的内部组成构件面临着复杂的变化。

2.要创建的复杂对象的算法，独立于该对象的组成部分，也独立于组成部分的装配方法时。