参考网站：设计模式
创建型模式
| 单例模式 | 原型模式 | 工厂方法模式 | 抽象工厂方法模式 | 建造者模式 |
|---|
单例模式
- 定义：指一个类只能有一个实例，且该类能自行创建这个实例的一种模式。例如，Windows中只能打开一个任务管理器，这样可以避免因打开多个任务管理器窗口而造成资源的浪费，或出现各个窗口显示内容的不一致等错误。
- 3个特点：
- 单例类只有一个对象
- 该单例对象必须由单例类自行创建
- 单例类对外提供一个访问该单例的全局访问点
- 优点：
- 单例模式可以保证内存里只有一个实例，减少了内存的开销。
- 可以避免对资源的多重占用
- 单例模式设置全局访问点，可以优化和共享资源的访问。
- 缺点：
- 单例模式一般没有接口，扩展困难。如果要扩展，则除了修改原来的代码，没有第二种途径。
- 在并发测试中，单例模式不利于代码调优。在调试过程中，如果单例中的代码没有执行完，也不能模拟生成一个新的对象。
- 单例模式的功能代码通常写在一个类中，如果功能设计不合理，则很容易违背单一职责的原则。
- 应用场景
- 需要频繁创建的一些类，使用单例可以降低系统的内存压力，减少GC。
- 某类只要求生成一个对象的时候。
- 某些类创建实例时占用资源较多，或实例化耗时较长，且经常使用。
- 频繁访问数据库或文件的对象。(只建立一次连接)
- 对于一些控制硬件级别的操作，或者从系统上讲应当是单一控制逻辑的操作，如果有多个实例，则系统会完全乱套。
- 当对象需要被共享时。由于单例模式只允许创建一个对象，共享该对象可以节省内存。
原型模式
- 定义：用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型相同或相似的新对象。在这里，原型实例指定了要创建的对象的种类。用这种方法创建对象非常高效，根本无需知道对象创建的细节。
- 模式的结构
由于Java提供了对象的clone()方法，所以用Java实现原型模式很简单。
原型模式包含以下主要角色：- 抽象原型类：规定了具体原型对象必须实现的接口
- 具体原型类：实现抽象原型类中的clone()方法，它是可被复制的对象
- 访问类：使用具体原型类中的clone()方法来复制新的对象
- 模式的实现：
原型模式的克隆分为浅克隆和深克隆- 浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型属性，仍指向原有属性所指向的对象的内存地址
- 深克隆：创建一个新对象，属性中引用的其他对象也会被克隆，不再指向原有对象地址。
- 应用场景：
- 对象之间相同或相似，即只是个别属性不同的时候
- 创建对象成本较大，例如初始化时间太长，占用CPU太多，或者占用网络资源太多等，需要优化资源
- 创建一个对象需要繁琐的数据准备和访问权限等，需要提高性能或者提高安全性
- 系统中大量使用该类对象，且各个调用者都需要给它重新赋值
简单(静态)工厂模式
- 工厂模式定义：定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类当中。
- 简单工厂模式：有一个具体的工厂类，可以生成多个不同的产品。
- 优点：
- 工厂类包含必要的逻辑判断，可以决定在什么时候创建哪一个产品的实例。客户端可以免除直接创建产品对象的职责，很方便地创建出相应的产品。工厂和产品的职责区分明确。
- 客户端无需知道所创建具体产品的类名，只需要知道参数即可。
- 也可以引入配置文件，在不修改客户端代码的情况下更换和添加新的具体产品类。
- 缺点：
- 简单工厂模式的工厂类单一，负责所有产品的创建，职责过重，一旦异常，整个系统将受影响。且工厂类代码会非常臃肿，违背高聚合原则。
- 使用简单工厂模式会增加系统中类的个数（引入新的工厂类），增加系统的复杂度和理解难度。
- 系统扩展困难，一旦增加新产品不得不修改工厂逻辑，在产品类型较多时，可能造成逻辑过于复杂
- 简单工厂模式使用static工厂方法，造成工厂角色无法形成基于继承的等级结构。
- 应用场景：
对于产品种类相对较少的情况，考虑使用简单工厂模式。使用简单工厂模式的客户端只需要传入工厂类的参数，不需要关心如何创建对象的逻辑，可以很方便地创建所需产品。 - 模式的结构：
- 简单工厂（SimpleFactory）：是简单工厂模式的核心，负责实现创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。
- 抽象产品（Product）：是简单工厂创建的所有对象的父类，负责描述所有实例共有的公共接口。
- 具体产品（ConcreteProduct）：是简单工厂模式的创建目标。
工厂方法模式
- 优点：
- 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程。
- 灵活性增强，对于新产品的创建，只需多写一个相应的工厂类。
- 高层模块只需要知道产品的抽象类，无须关心其他实现类。
- 缺点：
- 类的个数容易过多，增加复杂度
- 增加了系统的抽象性和理解难度
- 抽象产品只能生产一种产品，此弊端可以使用抽象工厂模式解决
- 应用场景：
- 客户只知道创建产品的工厂名，而不知道具体的产品名。
- 创建对象的任务由多个具体子工厂中的某一个完成，而抽象工厂只提供创建产品的接口。
- 客户不关心创建产品的细节，只关心产品的品牌
- 模式的结构
- 抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法 newProduct() 来创建产品。
- 具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
- 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。
-
具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。工厂方法模式
抽象工厂模式
- 定义：工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可以生产多个等级的产品。
- 使用场景：
- 系统中有多个产品族，每个具体工厂创建同一族但属于不同等级结构的产品
- 系统一次只可能消费其中某一族产品，即同组的产品一起使用
- 优点：
- 可以在类的内部对产品族中相关联的多等级产品共同管理，而不必专门引入多个新的类来进行管理。
- 当需要产品族时，抽象工厂可以保证客户端始终只使用同一个产品的产品族
- 抽象工厂增强了程序的可扩展性，当增加一个新的产品族时，不需要修改原代码
- 缺点：
当产品族中需要增加一个新的产品时，所有工厂类都需要进行修改。增加了系统的抽象性和理解难度 -
模式的结构：
同工厂方法模式一样，但是抽象工厂中方法个数不同，抽象产品的个数也不同
抽象工厂模式
建造者模式
- 定义：指将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示。它是将一个复杂的对象分解为多个简单的对象，然后一步一步构建而成。
- 优点：
- 封装性好，构建和表示分离。
- 扩展性好，各个具体的建造者相互独立，有利于系统的街耦
- 客户端不必知道产品内部组成的细节，建造者可以对创建过程逐步细化，而不对其它模块产生任何影响，便于控制细节风险
- 缺点：
- 产品的组成部分必须相同，这限制了其使用范围
- 如果产品的内部变化复杂，产品内部发生变化，则建造者也要同步修改，后期维护成本较大。
- 区别（与工厂模式）：
- 建造者模式更加注重方法的调用顺序，工厂模式注重创建对象。
- 创建对象的力度不同，建造者模式创建复杂的对象，由各种复杂的部件组成，工厂模式创建出来的对象都一样
- 关注重点不一样，工厂模式只需要把对象创建出来就可以了，而建造者模式不仅要创建出对象，还要知道对象由哪些部件组成。
- 建造者模式根据建造过程中的顺序不一样，最终对象部件组成也不一样。
- 模式的结构
- 产品角色（Product）：它是包含多个组成部件的复杂对象，由具体建造者来创建其各个零部件。
- 抽象建造者（Builder）：它是一个包含创建产品各个子部件的抽象方法的接口，通常还包含一个返回复杂产品的方法 getResult()。
- 具体建造者(Concrete Builder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。
- 指挥者（Director）：它调用建造者对象中的部件构造与装配方法完成复杂对象的创建，在指挥者中不涉及具体产品的信息。
- 应用场景：
- 相同的方法，不同的执行顺序，产生不同的结果
- 多个部件或零件，都可以装配到一个对象中，但是产生的结果又不相同。
- 初始化一个对象特别复杂，参数多，而且很多参数都具有默认值
