设计模式(1)简单工厂模式、工厂模式、抽象工厂模式

本文深入探讨了设计模式中的工厂模式,包括简单工厂模式、工厂方法模式和抽象工厂模式。详细解析了各种模式的优缺点,以及它们在软件开发中的应用,旨在帮助读者理解和掌握工厂模式的核心思想。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我有一个梦想,我写的代码,可以像诗一样优美。我有一个梦想,我做的设计,能恰到好处,既不过度,也无不足。

自工作以来,接触到设计模式也算有两年了,写一点东西记录一下。
设计模式:23种,牛逼的讲解书籍也有不少,网上也有不少相关资料,所以就只浅谈一下自己的理解。
先从工厂模式来吧。
工厂模式:1.简单工厂模式
2.工厂方法模式
3.抽象工厂模式

记得开始接触时,三种模式总是有点云里雾绕的感觉,后来才慢慢理解到其中的奥妙。

简单工厂模式
划分下:包含了:一个工厂类,一个抽象的产品类,多个具体的产品类(还有一种方式:没有显式写出工厂类,只包含了一个抽象的产品接口类,多个具体的产品类)

应用过程:
具体的产品类继承自抽象产品类(也叫接口类),在工厂类中根据使用端传入的参数,动态选择要实例化的具体产品类,返回一个抽象接口类的指针,由抽象接口类指针来操作实例化的产品。
第二种的应用过程:
在客户端中使用switch/case语句根据传入的参数选择要实例化的产品类(此时客户端就相当于拥有了一个工厂类,返回一个抽象接口类的指针,由抽象接口类指针来操作实例化的产品。)
优点
将产品的创建和使用分离,达到解耦的效果,使用者可以不关心产品的创建过程,只需要了解生产产品所对应的参数即可。

缺点
单个工厂的逻辑过重,所有的产品的选择生产都存在工厂实例中,耦合程度过高,一旦需要添加新的产品,不仅要实现新的产品类,还要对工厂类的内容进行更改,违反了“开放–封闭原则(即对扩展开放,对修改封闭)”。
第二种的:使用者必须清楚所有的产品类信息,一定程度上增加了使用者的使用难度

工厂方法
划分:
一个抽象的工厂接口类,多个具体工厂类,一个抽象的产品接口类,多个具体的产品类。

使用过程:
使用者(或者说是客户端)需要了解的有:两个抽象接口类,即一个抽象的工厂接口类,一个抽象的产品接口类。
每个具体工厂类继承自工厂接口类,每个具体产品类继承自产品接口类。每个工厂类中生产指定的产品(即创建过程),使用端指定具体工厂类,返回一个抽象的产品接口类指针指向具体产品。

优点
隐藏了产品的创建过程,使用端只需知道实例化哪儿个工厂类即可
克服了简单工厂模式违反“开放–封闭原则”的缺点,增加新的产品时,只需要增加继承自两个接口类的产品类和对应工厂类即可。
缺点
每个工厂只能生产一种产品,灵活性不高
每增加一个产品时,都要增加一个对应的工厂类,工作量会加大,适应场景应为产品种类变动较小的场景。

抽象工厂模式
划分:
一个抽象的工厂接口类,多个具体工厂类,不同类型的抽象的产品接口类,多个具体的产品类。

使用过程:
工厂类继承自工厂接口类,产品类继承自产品接口类,每个工厂中实现对不同类型产品的创建,返回对应类型的产品接口类指针,用以操作对应的产品。
用户端根据需求选择相应的工厂类实例化,通过该实例得到相应的产品的接口类指针指向对应的产品。
优点
克服了工厂方法模式每个工厂只能生产一种的产品的缺点
封装了产品的创建过程,使用端只关心使用。
可以生产不同种类的产品(这里提到了产品族,即一个工厂中的所有产品组成了一个产品族)
缺点
违反了“开闭原则”,每当增加一种产品的时候,所有工厂都要对应实现该接口。
当产品族中的产品种类过多时,对管理和使用端使用难度都会增加。

总结
简单工厂模式实际上不包含在23种设计模式,从模式的抽象程度上来说,工厂方法是简单工厂模式的进一步抽象并优化,将简单工厂模式的工厂类的高耦合优化为低耦合,而抽象工厂模式则是在工厂方法模式的基础上更进一步的抽象封装,是每个工厂都能够生产不同的产品。
总之:
无论是简单工厂模式还是工厂方法模式亦或是抽象工厂模式都是将产品的创建和使用进行分离,是使用端(客户端)在不必知道产品的创建过程的情况下能够正常“消费”该产品。
目的:达到用户界面和业务逻辑分离(即低耦合)的目的,方便后续系统的维护和管理。
先写这么多,有时间再更。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值