创建型设计模式

目录

01.单例模式设计思想

01.单例模式基础介绍

对于系统某些需求来说，保证一个实例很重要，比如文件管理系统，ID生成器等。为了保证实例只能被创建一次，因此这才有了单例模式！

单例模式特点，构造私有，单例类只有一个，反序列化不会重新构建对象，通过静态返回单例对象。

使用场景：应用中只存在一个实例，比如账号系统，数据库等。思考几个问题：为何使用单例，它存在什么问题，跟静态类有何区别，是否有替代方案？

02.单例模式设计思考

为何要使用单例？一个类只允许创建一个对象（或者实例），表示全局唯一的类，比如Android中数据库，所有数据操作都是指向一个数据库！

03.单例模式实现方式

如何实现单例：构造必须私有，避免外部创建；要考虑线程安全问题，避免多线程下创建多个对象；是否支持延迟加载；性能

  1. 方式1: 熟悉单例模式各自的优缺点和使用场景。
  2. 方式2: 饿汉式实现方式。
  3. 方式3: 懒汉式实现方式。
  4. 方式4: 双重DCL校验模式。这种用的最为广泛！
  5. 方式5: 静态内部类方式。
  6. 方式6: 枚举方式单例。
  7. 方式7: 容器实现单例模式。

有什么优点：1.提供全局访问【共享】；2.只有一个对象【对于高频率比较好】；3.使用简单。缺点也很明显：1.拓展难；2.指责不清晰；3.滥用单例导致对象状态丢失。

04.单例模式有那些不友好

单例对OOP不友好。单例违背了面向对象设计思想，不能搞封装，继承，多态等。如果强行实现面向对象，则会让人感到奇怪！

对代码类之间的依赖和可读性要注意。避免单例中内容太过于庞大，代码逻辑复杂导致维护比较难。

对代码拓展不友好。对可测试不够友好。不支持有参数的构造。

02.工厂模式设计思想

01.工厂模式设计

工厂模式分类，大概分为三种更加细分的类型：简单工厂、工厂方法和抽象工厂。一般情况下，使用简单工厂，工厂方法场景稍多。

工厂模式思考，主要要搞清楚应用场景。什么时候该用工厂模式？相对于直接 new 来创建对象，用工厂模式来创建究竟有什么好处呢？

思考一个题目，你要在店里买各种咖啡，而这些咖啡中有的加冰，有的加奶，有的加糖。比如美式咖啡，拿铁咖啡，摩卡咖啡，巴西咖啡等等！用简单工厂，工厂方法，抽象工厂分别实现。

02.简单工厂介绍

一句话概括简单工厂：可以根据参数的不同返回不同类的实例。

简单工厂模式包含如下角色：抽象产品角色，具体产品角色，工厂角色。

简单工厂实现：

  1. 创造抽象产品角色，比如总结出很多咖啡都可能会，加糖，加冰，加奶，因此把它抽成抽象方法。
  2. 具体产品角色，这块有：美式咖啡类，拿铁咖啡类，摩卡咖啡等，这些都是具体的咖啡产品。
  3. 工厂角色。负责创建不同咖啡，为了简便高效地分配咖啡，设了根据类型（比如american，latte）来提供不同的咖啡。

03.工厂方法介绍

工厂方法模式：定义一个创建对象的接口（指的是抽象工厂），让子类（具体工厂）决定实例化哪个产品类对象。工厂方法使一个产品类的实例化延迟到其工厂的子类。

工厂方法实现：

  1. Product：抽象产品。这个和简单工厂模式代码一样，忽略！
  2. ConcreteProduct：具体产品。这个和简单工厂模式代码一样，忽略！
  3. Factory：抽象工厂。这块定义咖啡工厂接口，通过该接口子类可以自己实现咖啡创建。
  4. ConcreteFactory：具体工厂。这里主要是创建美式咖啡工厂类，创建拿铁咖啡工厂类。

04.抽象工厂介绍

抽象工厂模式：抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级（即，同种的产品）的产品，而抽象工厂模式可生产多个等级（即，多种产品）的产品。

抽象工厂实现：

  1. AbstractFactory：抽象工厂。这个时候则需要抽象出生产甜品，生产咖啡的接口。
  2. ConcreteFactory：具体工厂。分别实现生产甜品的具体工厂，生产咖啡的具体工厂。
  3. AbstractProduct：抽象产品。这里把甜点抽象成一个产品，把咖啡抽象成一个产品。
  4. Product：具体产品。创建具体的美式咖啡，拿铁咖啡产品。创建具体的提拉米苏甜点，抹茶慕斯甜点。

03.建造者模式设计思想

01.建造者模式介绍

  1. 构造复杂对象的困境：通常使用构造函数或setter方法来设置对象的属性。但是，当对象具有许多属性或配置选项时，构造函数或setter方法的参数列表可能会变得冗长且难以维护。
  2. 建造者模式由来：在创建具有多个可选参数或配置选项的复杂对象，将对象的构建过程与其表示分离，使得构建过程更加灵活和可扩展。
  3. 建造者模式定义：建造者模式是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。
  4. 建造者模式场景：某个产品构建属性很多，或者属性之间存在依赖关系，或者同一个类可以创建不同的产品。
  5. 建造者模式思考：这种模式并不难，主要是理解应用场景，为什么要引入它？可以用set方式替换吗？

02.建造者模式实现

03.建造者模式分析

04.建造者案例实践

05.建造者模式拓展

06.建造者优缺点分析

07.构造者模式总结

04.原型模式设计思想

01.原型模式介绍

原型模式由来：看一个例子——邮件。由于邮件对象包含的内容较多（如发送者、接收者、标题、内容、日期、附件等），某系统中现需要提供一个邮件复制功能，则可以快速给不同的人发邮件【可以修改复制后的邮件内容】。

原型模式定义：提供了一种灵活的方式来创建对象，通过复制现有对象来创建新对象，从而避免了昂贵的对象创建过程。该模式的核心思想是通过复制现有对象来创建新对象，而不是通过实例化类来创建。

原型模式在以下情况下特别有用：

  1. 当对象的创建过程比较复杂或耗时时，可以通过复制现有对象来提高性能。
  2. 当需要创建多个相似对象，但又不希望与它们的具体类耦合时，可以使用原型模式。
贡献者: yangchong211