单例设计模式

所谓类的单例设计模式，就是采取一定的方法保证在整个的软件系统中，对某个类只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法(静态方法)。

单例设计模式八种方式

饿汉式(静态常量)

步骤：

构造器私有化 (防止 new )
类的内部创建对象
向外暴露一个静态的公共方法。getInstance

优缺点说明:

优点:这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
缺点:在类装载的时候就完成实例化，没有达到LazyLoading的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费
这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，在单例模式中大多数都是调用 getInstance 方法，但是导致类装载的原因有很多种，因此不能确定有其他的方式(或者其他的静态方法)导致类装载，这时候初始化 instance 就没有达到 lazy loading 的效果

结论：这种单例模式可用，可能造成内存浪费

饿汉式(静态代码块)

优缺点说明:

这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。

结论:这种单例模式可用，但是可能造成内存浪费

懒汉式(线程不安全)

优缺点说明:

起到了LazyLoading的效果，但是只能在单线程下使用。
如果在多线程下，一个线程进入了if(singleton==null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式。

结论:在实际开发中，不要使用这种方式.

懒汉式(线程安全，同步方法)

优缺点说明:

解决了线程安全问题
效率太低了，每个线程在想获得类的实例时候，执行getInstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接 return 就行了。方法进行同步效率太低

结论:在实际开发中，不推荐使用这种方式

懒汉式(线程安全，同步代码块)

不推荐使用，实际并不能实现线程安全

双重检查 🤔

优缺点说明:

Double-Check 概念是多线程开发中常使用到的，如代码中所示，我们进行了两次 if (singleton == null)检查，这样就可以保证线程安全了。
这样，实例化代码只用执行一次，后面再次访问时，判断if(singleton==null)，直接return实例化对象，也避免的反复进行方法同步
线程安全;延迟加载;效率较高
为什么要加volatile关键字

结论:在实际开发中，推荐使用这种单例设计模式

静态内部类 🤔

优缺点说明:

这种方式采用了类装载的机制来保证初始化实例时只有一个线程。
静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载 SingletonInstance 类，从而完成 Singleton 的实例化。
类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。
优点:避免了线程不安全，利用静态内部类特点实现延迟加载，效率高

结论:推荐使用

枚举 🤔

优缺点说明:

这借助JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。
这种方式是EffectiveJava作者JoshBloch提倡的方式

结论:推荐使用

单例模式在 JDK 应用

JDK中，java.lang.Runtime就是经典的单例模式. (饿汉式)

public class Runtime {
    private static Runtime currentRuntime = new Runtime();

    /**
     * Returns the runtime object associated with the current Java application.
     * Most of the methods of class <code>Runtime</code> are instance
     * methods and must be invoked with respect to the current runtime object.
     *
     * @return  the <code>Runtime</code> object associated with the current
     *          Java application.
     */
    public static Runtime getRuntime() {
        return currentRuntime;
    }

    /** Don't let anyone else instantiate this class */
    private Runtime() {}
}

单例模式注意事项和细节说明

单例模式保证了系统内存中该类只存在一个对象，节省了系统资源，对于一些需要频繁创建销毁的对象，使用单例模式可以提高系统性能
当想实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用new
单例模式使用的场景：需要频繁的进行创建和销毁的对象、创建对象时耗时过多或耗费资源过多(即:重量级对象)，但又经常用到的对象、工具类对象、频繁访问数据库或文件的对象(比如数据源、session 工厂等)

工厂模式

需求：

看一个披萨的项目:要便于披萨种类的扩展，要便于维护
披萨的种类很多(比如 GreekPizz、CheesePizz 等)
披萨的制作有 prepare，bake, cut, box
完成披萨店订购功能。

传统的方式的优缺点:

优点是比较好理解，简单易操作。
缺点是违反了设计模式的ocp原则，即对扩展开放，对修改关闭。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.
比如我们这时要新增加一个Pizza的种类(Pepper披萨)，只要是订购 Pizza 的代码都需要修改.

改进：把创建 Pizza 对象封装到一个类中，这样我们有新的 Pizza 种类时，只需要修改该类就可，其它有创建到 Pizza 对象的代码就不需要修改了–> 简单工厂模式

简单工厂模式

简单工厂模式(静态工厂模式)是属于创建型模式，是工厂模式的一种。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式
简单工厂模式：定义了一个创建对象的类，由这个类来封装实例化对象的行为
在软件开发中，当我们会用到大量的创建某种、某类或者某批对象时，就会使用到工厂模式.

改进方案：定义一个可以实例化Pizaa对象的类，封装创建对象的代码。

工厂方法模式

新的需求：披萨项目新的需求:客户在点披萨时，可以点不同口味的披萨，比如北京的奶酪 pizza、北京的胡椒 pizza 或者是伦敦的奶酪 pizza、伦敦的胡椒 pizza。

分析：

使用简单工厂模式，创建不同的简单工厂类，比如 BJPizzaSimpleFactory、LDPizzaSimpleFactory 等等.从当前这个案例来说，也是可以的，但是考虑到项目的规模，以及软件的可维护性、可扩展性并不是特别好。

使用工厂方法模式：

工厂方法模式设计方案:将披萨项目的实例化功能抽象成抽象方法，在不同的口味点餐子类中具体实现。
工厂方法模式:定义了一个创建 Pizza 对象的抽象方法，由子类工厂决定要实例化的类。工厂方法模式将对象的实例化推迟到子类。

抽象工厂模式

抽象工厂模式:定义了一个interface用于创建相关或有依赖关系的对象簇，而无需指明具体的类
抽象工厂模式可以将简单工厂模式和工厂方法模式进行整合。
从设计层面看，抽象工厂模式就是对简单工厂模式的改进(或者称为进一步的抽象)。
将工厂抽象成两层，AbsFactory(抽象工厂) 和具体实现的工厂子类。程序员可以根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇，更利于代码的维护和扩展。

工厂模式在 JDK-Calendar 应用的源码分析

// getInstance()
public static Calendar getInstance()
{
  return createCalendar(TimeZone.getDefault(), Locale.getDefault(Locale.Category.FORMAT));
}

//createCalendar() 根据 TimeZone zone, locale 创建对应的实例
private static Calendar createCalendar(TimeZone zone,Locale aLocale)
{
  CalendarProvider provider =
    LocaleProviderAdapter.getAdapter(CalendarProvider.class, aLocale)
    .getCalendarProvider();
  if (provider != null) {
    try {
      return provider.getInstance(zone, aLocale);
    } catch (IllegalArgumentException iae) {
      // fall back to the default instantiation
    }
  }

  Calendar cal = null;

  if (aLocale.hasExtensions()) {
    String caltype = aLocale.getUnicodeLocaleType("ca");
    if (caltype != null) {
      switch (caltype) { // ⚠️ 类似于不同口味的披萨
        case "buddhist":
          cal = new BuddhistCalendar(zone, aLocale);
          break;
        case "japanese":
          cal = new JapaneseImperialCalendar(zone, aLocale);
          break;
        case "gregory":
          cal = new GregorianCalendar(zone, aLocale);
          break;
      }
    }
  }
  if (cal == null) {
    // If no known calendar type is explicitly specified,
    // perform the traditional way to create a Calendar:
    // create a BuddhistCalendar for th_TH locale,
    // a JapaneseImperialCalendar for ja_JP_JP locale, or
    // a GregorianCalendar for any other locales.
    // NOTE: The language, country and variant strings are interned.
    if (aLocale.getLanguage() == "th" && aLocale.getCountry() == "TH") {
      cal = new BuddhistCalendar(zone, aLocale);
    } else if (aLocale.getVariant() == "JP" && aLocale.getLanguage() == "ja"
               && aLocale.getCountry() == "JP") {
      cal = new JapaneseImperialCalendar(zone, aLocale);
    } else {
      cal = new GregorianCalendar(zone, aLocale);
    }
  }
  return cal;
}

小结

工厂模式 (简单工厂模式、工厂方法模式、抽象工厂模式)的意义：

将实例化对象的代码提取出来，放到一个类中统一管理和维护，达到和主项目的依赖关系的解耦。从而提高项目的扩展和维护性。

设计模式的依赖抽象原则：

创建对象实例时，不要直接 new 类, 而是把这个 new 类的动作放在一个工厂的方法中，并返回。有的书上说，变量不要直接持有具体类的引用
不要让类继承具体类，而是继承抽象类或者是实现 interface(接口)
不要覆盖基类中已经实现的方法

原型模式

需求：

克隆羊问题：现在有一只羊，姓名为tom，年龄为1，颜色为白色，请编写程序创建和tom羊属性完全相同的10只羊。

传统方式实现

传统的方式的优缺点:

优点是比较好理解，简单易操作。
在创建新的对象时，总是需要重新获取原始对象的属性，如果创建的对象比较复杂时，效率较低
总是需要重新初始化对象，而不是动态地获得对象运行时的状态, 不够灵活

改进的思路分析:

Java 中 Object 类是所有类的根类，Object 类提供了一个 clone()方法，该方法可以将一个 Java 对象复制一份，但是需要实现clone的Java类必须要实现一个接口Cloneable，该接口表示该类能够复制且具有复制的能力 => 原型模式

原型模式实现

原型模式(Prototype模式)是指:用原型实例指定创建对象的种类，并且通过拷贝这些原型，创建新的对象
原型模式是一种创建型设计模式，允许一个对象再创建另外一个可定制的对象，无需知道如何创建的细节
工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建，即 对象.clone()

uml图：

Prototype : 原型类，声明一个克隆自己的接口
ConcretePrototype: 具体的原型类, 实现一个克隆自己的操作
Client: 让一个原型对象克隆自己，从而创建一个新的对象(属性一样)

原型模式在 Spring 框架中源码分析

//  prototype 多例的,原型模式
// <bean id="accountService" class="com.itheima.service.impl.AccountServiceImpl" scope="prototype" init-method="init" destroy-method="destroy"></bean>
IAccountService as = (IAccountService)ac.getBean("accountService");
IAccountService as2 = (IAccountService)ac.getBean("accountService");
System.out.println(as==as2); // false

// 1️⃣ getBean()
public Object getBean(String name) throws BeansException {
  assertBeanFactoryActive();
  return getBeanFactory().getBean(name);
}
// 2️⃣  getBeanFactory()
public final ConfigurableListableBeanFactory getBeanFactory() {
  synchronized (this.beanFactoryMonitor) {
    if (this.beanFactory == null) {
      throw new IllegalStateException("BeanFactory not initialized or already closed - " +
                                      "call 'refresh' before accessing beans via the ApplicationContext");
    }
    return this.beanFactory;
  }
}
// 3️⃣  getBean()
public Object getBean(String name) throws BeansException {
  return doGetBean(name, null, null, false);
}

// 4️⃣  doGetBean()
protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
			@Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
  ...
    else if (mbd.isPrototype()) {
      // It's a prototype -> create a new instance.
      Object prototypeInstance = null;
      try {
        beforePrototypeCreation(beanName);
        prototypeInstance = createBean(beanName, mbd, args); // ⚠️ 返回一个原型实例
      }
      finally {
        afterPrototypeCreation(beanName);
      }
      bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
    }
  ...
}

深入讨论-浅拷贝和深拷贝

浅拷贝的介绍:

对于数据类型是基本数据类型的成员变量，浅拷贝会直接进行值传递，也就是将该属性值复制一份给新的对象。
对于数据类型是引用数据类型的成员变量，比如说成员变量是某个数组、某个类的对象等，那么浅拷贝会进行引用传递，也就是只是将该成员变量的引用值(内存地址)复制一份给新的对象。因为实际上两个对象的该成员变量都指向同一个实例。在这种情况下，在一个对象中修改该成员变量会影响到另一个对象的该成员变量值
前面我们克隆羊就是浅拷贝
浅拷贝是使用默认的 clone()方法来实现 sheep = (Sheep) super.clone();

深拷贝基本介绍:

复制对象的所有基本数据类型的成员变量值
为所有引用数据类型的成员变量申请存储空间，并复制每个引用数据类型成员变量所引用的对象，直到该对象可达的所有对象。也就是说，对象进行深拷贝要对整个对象(包括对象的引用类型)进行拷贝
深拷贝实现方式1:重写clone方法来实现深拷贝
深拷贝实现方式2:通过对象序列化实现深拷贝(❗️推荐). code

原型模式的注意事项和细节

创建新的对象比较复杂时，可以利用原型模式简化对象的创建过程，同时也能够提高效率
不用重新初始化对象，而是动态地获得对象运行时的状态
如果原始对象发生变化(增加或者减少属性)，其它克隆对象的也会发生相应的变化，无需修改代码
在实现深克隆的时候可能需要比较复杂的代码
缺点：需要为每一个类配备一个克隆方法，这对全新的类来说不是很难，但对已有的类进行改造时，需要修改其源代码，违背了 ocp 原则。

建造者模式

需求：

盖房项目
1.需要建房子:这一过程为打桩、砌墙、封顶
2.房子有各种各样的，比如普通房，高楼，别墅，各种房子的过程虽然一样，但是要求不要相同的.

传统方式实现

问题分析：

优点是比较好理解，简单易操作。
设计的程序结构，过于简单，没有设计缓存层对象，程序的扩展和维护不好. 也就是说，这种设计方案，把产品(即:房子) 和创建产品的过程(即:建房子流程) 封装在一起，耦合性增强了。
解决方案:将产品和产品建造过程解耦 => 建造者模式.

建造者模式实现

建造者模式(BuilderPattern)又叫生成器模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来(抽象类别)，使这个抽象过程的不同实现方法可以构造出不同表现(属性)的对象。
建造者模式是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。

建造者模式的四个角色 🤔

Product(产品角色): 一个具体的产品对象。
Builder(抽象建造者): 创建一个 Product 对象的各个部件指定的接口/抽象类。
ConcreteBuilder(具体建造者): 实现接口，构建和装配各个部件。
Director(指挥者): 构建一个使用 Builder 接口的对象。它主要是用于创建一个复杂的对象。它主要有两个作用，一是:隔离了客户与对象的生产过程，二是:负责控制产品对象的生产过程。

建造者模式解决盖房需求应用实例：

需要建房子:这一过程为打桩、砌墙、封顶。不管是普通房子也好，别墅也好都需要经历这些过程，下面我们使用建造者模式(Builder Pattern)来完成： code

建造者模式在 JDK 的应用和源码分析

java.lang.StringBuilder 中的建造者模式

Appendable 接口定义了多个 append 方法(抽象方法), 即 Appendable 为抽象建造者, 定义了抽象方法
AbstractStringBuilder 实现了 Appendable 接口方法，这里的 AbstractStringBuilder 已经是建造者，只是不能实例化
StringBuilder 即充当了指挥者角色，同时充当了具体的建造者，建造方法的实现是由 AbstractStringBuilder 完成, 而 StringBuilder 继承了 AbstractStringBuilder

建造者模式的注意事项和细节

客户端(使用程序)不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象
每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者， 用户使用不同的具体建造者即可得到不同的产品对象
可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程
增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合“开闭原则”
建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大，因此在这种情况下，要考虑是否选择建造者模式.
抽象工厂模式VS建造者模式 ⚠️

抽象工厂模式实现对产品家族的创建，一个产品家族是这样的一系列产品:具有不同分类维度的产品组合，采用抽象工厂模式不需要关心构建过程，只关心什么产品由什么工厂生产即可。而建造者模式则是要求按照指定的蓝图建造产品，它的主要目的是通过组装零配件而产生一个新产品

Java设计模式之创建型模式

Java设计模式之创建型模式

单例设计模式