抽象工厂和工厂方法模式的比较(转载)

本文介绍了抽象工厂模式的概念,区分了产品等级结构与产品族,并通过汽车制造实例对比了工厂方法模式与抽象工厂模式的不同。

来源:http://blog.youkuaiyun.com/zhengzhb/article/details/7359385/     抽象工厂模式

http://blog.youkuaiyun.com/mark_lq/article/details/45132113  等级结构和产品族

定义:为创建一组相关或相互依赖的对象提供一个接口,而且无需指定他们的具体类。

类型:创建类模式

类图:

比较:

在抽象工厂模式中,有一个产品族的概念:所谓的产品族,是指位于不同产品等级结构中功能相关联的产品组成的家族。抽象工厂模式所提供的一系列产品就组成一个产品族;而工厂方法提供的一系列产品称为一个等级结构。我们依然拿生产汽车的例子来说明他们之间的区别。


(1) 产品等级结构:产品等级结构即产品的继承结构,如一个抽象类是汽车工厂,其子类有两厢车,三厢车,则抽象汽车工厂与具体汽车中之间构成了一个产品等级结构,抽象汽车是父类,而具体的(多少)厢的汽车是其子类。
 (2) 产品族:在抽象工厂模式中,产品族是指由同一个工厂生产的,位于不同产品等级结构中的一组产品,如汽车工厂生产的两厢汽车,三厢汽车,2.0排量的两厢汽车位于两厢汽车等级结构中,2.4排量的三厢汽车位于三厢汽车等级结构中,2.0排量的两厢汽车、2.4排量的三厢汽车构成了一个产品族。

等级结构和产品族详解:http://blog.youkuaiyun.com/mark_lq/article/details/45132113



车的生产类图

  在上面的类图中,两厢车和三厢车称为两个不同的等级结构;而2.0排量车和2.4排量车则称为两个不同的产品族。再具体一点,2.0排量两厢车和2.4排量两厢车属于同一个等级结构,2.0排量三厢车和2.4排量三厢车属于另一个等级结构;而2.0排量两厢车和2.0排量三厢车属于同一个产品族,2.4排量两厢车和2.4排量三厢车属于另一个产品族。

明白了等级结构和产品族的概念,就理解工厂方法模式和抽象工厂模式的区别了,如果工厂的产品全部属于同一个等级结构,则属于工厂方法模式;如果工厂的产品来自多个等级结构,则属于抽象工厂模式。在本例中,如果一个工厂模式提供2.0排量两厢车和2.4排量两厢车,那么他属于工厂方法模式;如果一个工厂模式是提供2.4排量两厢车和2.4排量三厢车两个产品,那么这个工厂模式就是抽象工厂模式,因为他提供的产品是分属两个不同的等级结构。当然,如果一个工厂提供全部四种车型的产品,因为产品分属两个等级结构,他当然也属于抽象工厂模式了。

<think>好的,我需要帮助用户分析简单工厂模式的缺点局限性。首先,我应该回顾一下用户提供的引用内容,看看里面有没有相关的信息。 引用[1]提到:“缺点:实现复杂,不适合简单的应用场景。对开闭原则的支持也有一定的局限性,当需要增加新的产品对象种类时,需要修改抽象工厂所有具体工厂的代码。” 这里直接指出了简单工厂模式的缺点,特别是关于开闭原则的问题。需要扩展时,必须修改工厂类,这不符合开闭原则的“对扩展开放,对修改关闭”的要求。 引用[4]是转载的一篇分析简单工厂模式优缺点的文章,可能里面有更详细的说明。虽然具体内容看不到,但根据引用[1]的描述,可以推测它可能讨论了类似的问题,比如工厂类职责过重、扩展困难等。 接下来,我需要整理这些信息,用中文清晰地解释简单工厂模式的缺点局限性。要确保结构清晰,分点列出,每个点都给出具体的例子或说明,让用户容易理解。同时,要遵循用户给出的系统级指令,比如正确使用LaTeX格式,生成相关问题,并在引用处添加标识。 需要注意的是,用户可能混淆了简单工厂模式抽象工厂模式,因为引用[3]提到了抽象工厂模式,但用户的问题是关于简单工厂模式的。因此,在回答时要明确区分,避免混淆。 最后,生成的相关问题应该围绕简单工厂模式的缺点展开,例如与其他工厂模式的对比、适用场景等,帮助用户进一步学习。</think>### 简单工厂模式的缺点及局限性分析 简单工厂模式通过集中化的工厂类创建对象,简化了客户端代码,但其核心问题在于**对系统扩展性设计灵活性的限制**。以下是具体分析: #### 1. **违反开闭原则** 开闭原则要求“对扩展开放,对修改关闭”,但简单工厂模式在新增产品类型时,必须修改工厂类的代码。例如: ```java public class SimpleFactory { public Product createProduct(String type) { if (type.equals("A")) { return new ProductA(); } else if (type.equals("B")) { // 新增产品C时需在此处添加条件分支 return new ProductB(); } return null; } } ``` 每次新增产品类型(如`ProductC`)都需要修改`createProduct`方法,导致工厂类频繁变动[^1][^4]。 #### 2. **工厂类职责过重** 工厂类承担了所有产品的创建逻辑,随着产品种类增多,代码会变得臃肿且难以维护。例如: - 需要处理多个产品的创建逻辑(如不同品牌的手机) - 包含复杂的条件分支(如根据参数选择不同构造方式) 这会使工厂类成为系统性能瓶颈,并增加单点故障风险[^2]。 #### 3. **类型判断冗余** 客户端需通过字符串或枚举类型标识产品类别,例如: ```python factory.create_product("LED") # 传递字符串参数指定产品类型 ``` 若参数传递错误(如拼写错误),会导致运行时异常而非编译时错误,降低代码健壮性。 #### 4. **难以应对多层级产品结构** 当产品存在多个层级或维度时(如“手机+耳机”组合产品),简单工厂模式无法优雅地扩展。例如: - 需要创建`旗舰手机+降噪耳机``入门手机+普通耳机`的组合 - 需在工厂类中硬编码所有组合关系,导致代码复杂度激增 此时更适合使用**抽象工厂模式**,通过多个工厂类分别处理不同产品[^3]。 #### 5. **单元测试困难** 由于工厂类直接耦合具体产品实现,测试时难以通过**依赖注入**替换为Mock对象。例如: ```java // 测试代码无法轻松替换RealProduct为MockProduct Product obj = SimpleFactory.createProduct("Real"); ``` --- ### 适用场景建议 简单工厂模式适用于以下场景: 1. 产品种类较少且稳定(如不超过5种) 2. 客户端不关心具体创建过程 3. 需要集中化控制对象创建逻辑(如配置化对象生成) 若系统需要频繁扩展新产品类型,建议改用**工厂方法模式**(每个产品对应独立工厂)或**抽象工厂模式**(支持产品扩展)。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值