【一】Java 设计模式学习记录：工厂模式

最新推荐文章于 2022-07-14 19:26:46 发布

Genmer

最新推荐文章于 2022-07-14 19:26:46 发布

阅读量319

点赞数

分类专栏：学习设计模式文章标签：设计模式 java spring

本文链接：https://blog.csdn.net/Genmer/article/details/119669940

版权

学习同时被 2 个专栏收录

33 篇文章 2 订阅

订阅专栏

设计模式

3 篇文章 0 订阅

订阅专栏

文章目录

前面先学习了Java设计模式[前置] - 设计模式七大原则，接下来看看

一、设计模式的分类

设计模式分为3种类型，共23种

创建型模式:单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式
- 关注对象的创建 - 对象怎么设计
结构型模式:适配器模式、桥接模式、装饰模式、组合模武、外观模式、享元模式、代理模式
- 关注软件（系统）结构 - 怎么让软件更加具有扩展性
行为型模式:模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模武、备忘录模式、解释器模式( Interpreter模式)、状态模式、策略模式、职责链模式(责任链模式)
- 站在方法的角度，怎么设计方法更加合理

二、工厂模式

工厂模式中的三种：简单工厂模式、工厂方法模式、抽象工厂模式；实现了创建者和调用者的分离，调用者不需要知道具体的创建者是什么类，只需要知道工厂的接口以及自己想要的产品名称，就可以进行调用得到想要的产品

2.1 简单工厂模式

2.1.1 解决的问题

将“类实例化的操作”与“调用方”分离，使得调用方不用知道具体参数就可以实例化出所需要的“产品”类，从而避免了在客户端代码中显式指定，实现了解耦。

2.1.2 简单工厂模式是什么

简单工厂模式是属于创建型模式,是工厂模式的一种。简单工厂模式是由个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式。
简单工厂模式也称为静态工厂模式，工厂类一般采用静态方法，根据接收的参数不同来确定返回对象实例，但简单工厂模式违反了开闭原则，一旦添加新产品就不得不修改工厂类的逻辑，这样就会造成工厂逻辑过于复杂。

2.1.3 优缺点

优点
- 将创建实例的工作与使用实例的工作分开，使用者不必关心类对象如何创建，实现了解耦；
- 把初始化实例时的工作放到工厂里进行，使代码更容易维护。更符合面向对象的原则 & 面向接口编程（依赖倒转原则），而不是面向实现编程。
缺点
- 工厂类集中了所有实例（产品）的创建逻辑，一旦这个工厂不能正常工作，整个系统都会受到影响；
- 违背“开放 - 关闭原则”（OCP），一旦添加新产品就不得不修改工厂类的逻辑，且产品数量一多这样就会造成工厂逻辑过于复杂。
- 简单工厂模式由于使用了静态工厂方法，静态方法不能被继承和重写，会造成工厂角色无法形成基于继承的等级结构。

2.2 工厂方法模式

2.2.1 解决的问题

简单工厂模式得缺点，工厂里得产品每次新增都要修改代码
当每个单品又有多个分类，比如电器商城，有买冰箱，电视机，如果使用简单工厂模式，再新增一个微波炉，他就得新增一条产品线（钱要多花，商场本身又要有个地方做这个产品）。

2.2.2工厂方法模式是什么

工厂方法模式把具体产品的创建推迟到工厂类的子类（具体工厂）中，此时工厂类不再负责所有产品的创建，而只是给出具体工厂必须实现的接口，这样工厂方法模式在添加新产品的时候就不修改工厂类逻辑而是添加新的工厂子类，符合开放封闭原则，克服了简单工厂模式中缺点。

工厂模式可以说是简单工厂模式的进一步抽象和拓展，在保留了简单工厂的封装优点的同时，让扩展变得简单，让继承变得可行，增加了多态性的体现。

上面的例子来说，简单工厂模式商场卖的电视，冰箱都是自己做的，工厂方法模式就是找电视厂和冰箱厂来外包这个活，商场本身只需要售卖即可。

2.2.3 优缺点

优点
- 更符合开-闭原则OCP
  - 新增一种产品时，只需要增加相应的具体产品类和相应的工厂子类即可（简单工厂模式需要修改工厂类的判断逻辑）
- 符合单一职责原则
  - 每个具体工厂类只负责创建对应的产品（简单工厂中需要判断各种种类得处理）
- 不使用静态工厂方法，可以形成基于继承的等级结构。（简单工厂模式的工厂类使用静态工厂方法无法被继承）
缺点
- 添加新产品时，除了增加新产品类外，还要提供与之对应的具体工厂类，类的个数将成对增加，在一定程度上增加了系统的复杂度；同时，有更多的类需要编译和运行，会给系统带来一些额外的开销；
- 虽然保证了工厂方法内的对修改关闭，但对于使用工厂方法的类，如果要更换另外一种产品，仍然需要修改实例化的具体工厂类；
- 一个具体工厂只能创建一种具体产品

工厂方法模式设计方案: 将工厂实例化产品得功能抽象成抽象方法,在不同的分类子类中具体实现
工厂方法模式: 定义了一个创建对象的抽象方法,由子类决定要实例化的类。工厂方模式将对象的实例化推迟到子类

2.3 抽象工厂模式

问题又出现了
工厂方法模式就是找电视厂和冰箱厂来外包这个活，商场本身只需要售卖即可。
当需求发生变化，当工厂需要新增一个洗衣机的话，他有需要投资或者找一个新的工厂来做。
后来，商场发现可以直接找知名厂商来进货，比如海尔，直接买海尔的冰箱电视机，当需要洗衣机，需要变动的是海尔（工厂），而不是商场（调用方）。

这样看来挺完美的，但现实一般有各个品牌的粉丝，比如还有格力，小米（0.0），那么只卖一个品牌一般是不行的（授权商除外），所以抽象工厂引出了一个产品簇（族）和产品等级的概念。
在这里插入图片描述
海尔，格力，小米就是产品簇（品牌），电视机，冰箱，洗衣机是产品的等级结构（可以理解为产品类型）

2.3.1 解决的问题

工厂方法模式下，一个工厂，只能处理一种产品

在抽象模式下，一个商场可以同时售卖更多品牌和种类的产品
这里注意：可以用抽象工厂处理的情况中，需要确定这个产品集合（冰箱洗衣机电视）

2.3.2 抽象工厂模式是什么

抽象工厂模式其实就算将简单工厂模式和工厂方法模式进行整合。
从设计层面来看，抽象工厂模式就算对简单工厂模式的改进（或者进一步抽象）。
将工厂抽象成两层，工厂和角色，他们的类主要有以下4种
- AbstractFactory：抽象工厂角色，如抽象的电器工厂类，它声明了一组用于创建一种产品的方法，每一个方法对应一种产品，如生产电视机和生产电冰箱。
- ConcreteFactory：具体工厂角色，如海尔工厂类和小米美工厂类，它实现了在抽象工厂中定义的创建产品的方法，生成一组具体产品，这些产品构成了一个产品族，每一个产品都位于某个产品等级结构中。
- AbstractProduce：抽象产品角色，如冰箱电视类，它为每种产品声明接口。
- ConcreteProduce：具体产品角色，如海尔冰箱类，海尔电视类，美的冰箱类，美的电视类，它定义具体工厂生产的具体产品对象，实现抽象产品接口中声明的业务方法。

2.3.3 优缺点

优点
- 降低耦合
- 抽象工厂模式将具体产品的创建延迟到具体工厂的子类中，这样将对象的创建封装起来，可以减少客户端与具体产品类之间的依赖，从而使系统耦合度低，这样更有利于后期的维护和扩展；
缺点
- 抽象工厂模式很难支持新种类产品的变化。
- 这是因为抽象工厂接口中已经确定了可以被创建的产品集合，如果需要添加新产品，此时就必须去修改抽象工厂的接口，这样就涉及到抽象工厂类的以及所有子类的改变，这样也就违背了“开发——封闭”原则。

对于新的产品族符合开-闭原则；对于新的产品种类不符合开-闭原则，这一特性称为开-闭原则的倾斜性。