设计模式——创建型

一、单例模式

设计模式——创建型：单例模式

二、工厂方法模式

1、简单工厂模式

为了让类的职责更加单一、代码更加清晰，将函数剥离到一个独立的类中，让这个类只负责对象的创建，这个类就是简单工厂模式类。

• 第一种实现方式：

public class RuleConfigParserFactory {
	
	public static IRuleConfigParser createParser(String config) {
		RuleConfigParser parser = null;
		if ("json".equalse(config) {
			parser = new JsonRuleConfigParser();
		} else ("xml".equalse(config) {
			parser = new XmlRuleConfigParser();
		}
		.....
		return parser;
	}
}

• 第二种实现方式：单例模式与工厂模式组合
  如果parser可以复用，为了节省内存和对象创建时间，可以将parser事先创建好缓存起来。

private static final Map<String, RuleConfigParser> cachedParsers = new HashMap<>();

static {
	cachedParsers.put("json", new JsonRuleConfigParser());
	cachedParsers.put("xml", new XmlRuleConfigParser());
}

2、工厂方法

创建逻辑比较复杂，简单工厂和工厂方法比较常用，抽象工厂的应用场景比较特殊。
当创建逻辑比较复杂，是一个大工程的时候，就考虑使用工厂模式，将对象的创建和使用相分离。

①类似规则配置解析的例子代码中存在if else分支判断动态的根据不同的类型创建不同的对象，可考虑使用工厂模式将if else创建对象的代码抽离出来，放在工厂类中。
②尽管不需要根据不同的类型创建不同的对象，但是单个对象本身的创建过程比较复杂，如需组合其他类对象，做各种初始化操作，也可考虑工厂模式，将对象的创建过程封装到工厂类中。

对于①中，当每个对象的创建逻辑都比较简单的时候，推荐使用简单工厂模式，将多个对象的创建逻辑放在一个工厂类中。当每个对象的创建逻辑都比较复杂的时候，为了避免设计一个过于庞大的简单工厂类，推荐使用工厂方法模式，将创建逻辑拆分的更细，每个对象的创建逻辑独立到各自的工厂类中。
同理，对于②中单个对象本身的创建逻辑就比较复杂。建议使用工厂模式。

判断要不要使用工厂模式的本质的参考标准：

• 封装变化：创建逻辑有可能变化，封装成工厂之后变得更透明。
• 代码复用：创建代码抽离到独立的工厂内之后可以复用。
• 隔离复杂性：封装复杂的创建逻辑，调用者无需了解如何创建。
• 控制复杂度：将创建代码抽离出来，让原本函数式类职责更单一。

3、工厂模式和依赖注入容器（Dependency Injection Container，简称DI容器）的区别

DI容器底层设计思想就是基于工厂模式的。DI容器相当于一个大的工厂类，负责在程序启动的时候，根据配置（要创建哪些类对象，每个类对象的创建需要依赖哪些其他类对象）事先创建好对象，当应用程序需要使用某个类对象的时候，直接从容器中获取即可，正是因为它持有一堆对象，所以这个框架才被称为容器。

工厂模式中一个工厂类只负责某个类对象或者某一组相关类对象（继承自同一抽象类或者接口的子类）的创建。而DI容器负责的是整个应用中所有类对象的创建，还负责配置的解析，对象生命周期的管理。

DI容器的核心功能：
配置解析、对象创建和对象生命周期管理。
通过读取配置文件，根据配置文件提供的信息来创建对象。将所有类对象的创建都放在工厂类BeansFactory中，在spring中可配置scope属性来区分这两种不同类型的对象。

scope = prototype 表示返回新创建的对象
scope = singleton 表示返回单例对象

此外，lazy-init = true 配置对象支持懒加载；配置对象init-method 和 destroy-method 方法，DI容器在创建好对象之后，会主动调用init-method属性指定的方法来初始化对象，在销毁前，主动调用destroy-method指定的方法。

4、如何实现一个简单的DI容器

用Java语言来实现一个简单的DI容器，核心逻辑只需要包括这两部分：配置文件解析，根据配置文件通过“反射”语法来创建对象。

• 最小原型设计
• 提供执行入口
• 配置文件解析
• 核心工程类设计

BeansFactory 是DI容器最核心的一个类了，负责根据从配置文件解析得到的BeanDefinition创建对象。
如果对象的scope属性是singleton，那对象创建之后会会缓存在singletonObjects这样一个map中，下次请求时，直接从map中取出返回，不需要重新创建。
如果对象的scope属性是prototype，每次请求都创建一个新对象。
BeansFactory创建对象用到的主要技术就是反射：在程序运行的过程中，动态的加载类、创建对象、不需要事先在代码中写死要创建哪些对象。

JVM在启动的时候会根据代码自动地加载类、创建对象。至于都要加载哪些类、创建哪些对象，都是在代码中写死的，提前写好的，但如果某个对象的创建并不是写死在代码中，而是放在配置文件中，在程序运行期间，动态的根据配置文件来加载类，创建对象。JVM无法自动完成，需利用反射机制去编写代码。

三、建造者模式（Builder）

1、定义

将一个复杂的对象的构建与它的表示分离。即使同样的构建过程可以创建不同的表示。

2、为什么要使用建造者模式

如果一个类中有很多属性，为了避免构造函数的参数列表过长，影响代码的可读性和易用性，可通过构造函数配合set方法来解决。

使用建造者模式的情况：

• 我们把类的必填属性放在构造函数中，强制创建对象的同时就设置，如果必填的属性有很多，把这些必填属性都放在构造函数中设置，那构造函数就又会出现列表很长的问题。如果我们把必填属性通过set（）方法设置，那校验这些必填属性是否已经填写的逻辑就无处安放了。
• 如果类的属性之间有一定的依赖关系或者约束条件，我们继续使用构造函数配合set（）方法设置思路，那这些依赖关系或约束条件的校验就无处安放了。
• 如果希望创建不可变对象，即创建号之后，就不能再修改内部的属性值，要实现这个功能，就不能在类中暴露set（）方法，构造函数配合set（）方法来设置属性值的方式就不适合用了。

3、建造者的实现方式：

一种是单独定义一个Builder类，一种是将Builder实现为原始类的内部类。

4、建造者模式与工厂方法模式的区别

• 工厂模式是用来创建不同但是相关类型的对象（继承同一父类或者接口的一组子类），由给定的参数类决定创建哪种类型的对象。
• 建造者模式是用来创建一种类型的复杂对象，通过设置不同的可选参数，“定制化”地创建不同的对象。

四、原型模式（Prototype Design Pattern）

1、原型模式的原理与应用

如果对象的创建成本比较大，而同一个类的不同对象之间差别不大（大部分字段都相同，在这种情况下可以利用对已有对象（原型）进行复制（拷贝）的方式来创建新对象，以达到节省创建时间的目的，这种基于原型来创建对象的方式就叫做原形设计模式，简称原形模式。

为何对象的创建成本比较大？

实际上创建对象包含的申请内存、给成员变量赋值这一过程本身并不会花费太多时间，或者说对于大部分业务系统来说，这些时间完全是可以忽略的，应用一个复杂的模型只得到一点点的性能提升，就是所谓的过渡设计、得不偿失。
但是如果对象中的数据需要经过复杂的计算才能得到，（比如排序、计算哈希值），或者需要从PC网络，数据库，文件系统等非常慢速的io中读取，这种情况下就可以使用原型模式从其他已有对象中直接拷贝得到，而不用每次在创建新对象的时候都重复执行这些耗时的操作。

2、原型模式的两种实现方法:深拷贝与浅拷贝

• 浅拷贝只会复制对象中基本数据类型数据和引用数据的对象内存地址，不会递归的复制引用对象、以及引用对象的引用对象…即浅拷贝得到的对象跟原始对象共享数据。
• 深拷贝不仅会复制索引，还会复制数据本身，得到的是一份完完全全的独立对象。所以深拷贝比浅拷贝来说更加厚实，更加耗内存空间。

深拷贝的实现方法:

①递归拷贝对象，对象的引用对象，以及……，直到要拷贝的对象只包含基本数据类型，没有引用对象为止。
②先将对象序列化，然后再反序列化成新的对象。

如果要拷贝的对象是不可变对象，浅拷贝共享不可变对象是没有问题的，对于可变对象来说，浅拷贝得到的对象和原始对象会共享部分数据，就有可能出现数据被修改的风险。除非像从数据库中加载10万条数据并构建散列表索引操作非常耗时，比较推荐使用浅拷贝，否则没有充分的理由，不要为了一点点的性能提升使用浅拷贝。

深拷贝与浅拷贝建议不要混合使用，
clone与final两对冤家，对象的clone与对象内的final属性是有冲突的
①类初始化要消化非常多的资源，包括数据、硬件资源等
②通过new产生一个对象需要非常繁琐的数据准备或者访问权限
③一个对象需要提供其他对象访问，而且各个调用者都可能需要修改其值。