3. 抽象工厂
3. 抽象工厂模式(使用频率:★★★★★)
- 工厂方法模式
每个具体工厂只有一个或者一组重载的工厂方法,只能生产一种产品,可能会导致系统中存在大量的工厂类,势必会增加系统的开销
- 抽象工厂模式
一个工厂可以生产一系列产品(一族产品),极大减少了工厂类的数量
1. 概念
-
产品等级结构:产品等级结构即产品的继承结构
-
产品族:产品族是指由同一个工厂生产的,位于不同产品等级结构中的一组产品
- 模式动机
当系统所提供的工厂生产的具体产品并不是一个简单的对象,而是多个位于不同产品等级结构、属于不同类型的具体产品时就可以使用抽象工厂模式
抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形式
- 工厂模式定义
抽象工厂模式:提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。又称为工具(Kit)模式
抽象工厂模式中的具体工厂不只是创建一种产品,它负责创建一族产品
当一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象时,抽象工厂模式比工厂方法模式更为简单、更有效率
2. 抽象工厂模式结构
抽象工厂模式包含以下4个角色:
-
AbstractFactory(抽象工厂)
-
ConcreteFactory(具体工厂)
-
AbstractProduct(抽象产品)
-
ConcreteProduct(具体产品)
3. 抽象工厂代码实现
- 典型的抽象工厂类代码
public interface AbstractFactory { public AbstractProductA createProductA(); //工厂方法一 public AbstractProductB createProductB(); //工厂方法二 …… }
- 典型的具体工厂类代码
public class ConcreteFactory1 implements AbstractFactory { //工厂方法一 public AbstractProductA createProductA() { return new ConcreteProductA1(); } //工厂方法二 public AbstractProductB createProductB() { return new ConcreteProductB1(); } …… }
4. 例子
某软件公司要开发一套界面皮肤库,可以对基于Java的桌面软件进行界面美化。用户在使用时可以通过菜单来选择皮肤,不同的皮肤将提供视觉效果不同的按钮、文本框、组合框等界面元素,例如春天(Spring)风格的皮肤将提供浅绿色的按钮、绿色边框的文本框和绿色边框的组合框,而夏天(Summer)风格的皮肤则提供浅蓝色的按钮、蓝色边框的文本框和蓝色边框的组合框,其结构示意图如下图所示
该皮肤库需要具备良好的灵活性和可扩展性,用户可以自由选择不同的皮肤,开发人员可以在不修改既有代码的基础上增加新的皮肤。
现使用抽象工厂模式来设计该界面皮肤库。
(1) Button:按钮接口,充当抽象产品
(2) SpringButton:Spring按钮类,充当具体产品
(3) SummerButton:Summer按钮类,充当具体产品
(4) TextField:文本框接口,充当抽象产品
(5) SpringTextField:Spring文本框类,充当具体产品
(6) SummerTextField:Summer文本框类,充当具体产品
(7) ComboBox:组合框接口,充当抽象产品
(8) SpringComboBox:Spring组合框类,充当具体产品
(9) SummerComboBox:Summer组合框类,充当具体产品
(10) SkinFactory:界面皮肤工厂接口,充当抽象工厂
(11) SpringSkinFactory:Spring皮肤工厂,充当具体工厂
(12) SummerSkinFactory:Summer皮肤工厂,充当具体工厂
(13) Client:客户端测试类
更换皮肤只需要更改配置文件
<?xml version="1.0"?> <config> <className>designpatterns.abstractfactory.SpringSkinFactory </className> </config>
5. 拓展产品
-
增加产品族(工厂)
对于增加新的产品族,抽象工厂模式很好地支持了开闭原则,只需要增加具体产品并对应增加一个新的具体工厂,对已有代码无须做任何修改
-
增加新的产品等级结构
对于增加新的产品等级结构,需要修改所有的工厂角色,包括抽象工厂类,在所有的工厂类中都需要增加生产新产品的方法,违背了开闭原则
6. 优缺点
-
优点
隔离了具体类的生成,使得客户端并不需要知道什么被创建
当一个产品族中的多个对象被设计成一起工作时,它能够保证客户端始终只使用同一个产品族中的对象
增加新的产品族很方便,无须修改已有系统,符合开闭原则
-
缺点
增加新的产品等级结构麻烦,需要对原有系统进行较大的修改,甚至需要修改抽象层代码,这显然会带来较大的不便,违背了开闭原则
7. 模式适用环境
一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节
系统中有多于一个的产品族,但每次只使用其中某一产品族
属于同一个产品族的产品将在一起使用,这一约束必须在系统的设计中体现出来
产品等级结构稳定,在设计完成之后不会向系统中增加新的产品等级结构或者删除已有的产品等级结构
用环境
一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节
系统中有多于一个的产品族,但每次只使用其中某一产品族
属于同一个产品族的产品将在一起使用,这一约束必须在系统的设计中体现出来
产品等级结构稳定,在设计完成之后不会向系统中增加新的产品等级结构或者删除已有的产品等级结构
本文来自博客园,作者:墨镜一戴谁也不爱,转载请注明原文链接:https://www.cnblogs.com/hnuzmh/p/16196514.html
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了