[设计模式03]-抽象工厂

本文介绍了一种改进简单工厂模式的设计方案——抽象工厂模式。通过职责单一化的工厂设计,解决了产品扩展时需要修改工厂类的问题。文章详细展示了如何通过创建特定的产品工厂类来遵循单一职责原则。

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

      上一个章节简单工厂模式中,如果增加产品C,那么则需要修改工厂类的逻辑代码。如果这种情形发生在现实中,我们的解决方案是,增加产品C,增加生产产品C的工厂就可以了。修改工厂类的逻辑显然是不合理的。如果按照单一职责的原则,工厂应该只负责相应产品的生产,而不应该根据类别生产产品,换句话说就是工厂应该职责单一化,按照这种思路,我们针对每一种产品建立工厂。我们再在具体工厂的基础上抽象出一个类出来,这样就能够实现增加产品时,只需要增加相应的工厂,不需要改动工厂类代码。

      抽象工厂在简单工程的基础上,进一步解决了扩展时需要修改工厂类逻辑代码的问题。解决方式是工厂职责明确化,再抽提工厂类。

ProductFactory

namespace SimpleFactory
{
    public abstract class ProductFactory
    {
        public abstract Product CreateProduct();
    }
}

ProductAFactory

namespace SimpleFactory
{
    public class ProductAFactory : ProductFactory
    {
        public override Product CreateProduct()
        {
            return new ProductA();
        }
    }
}

ProductBFactory

namespace SimpleFactory
{
    public class ProductBFactory : ProductFactory
    {
        public override Product CreateProduct()
        {
            return new ProductB();
        }
    }
}

调用者:

ProductFactory factory = null;

factory = new ProductAFactory();
factory.CreateProduct();

factory = new ProductBFactory();
factory.CreateProduct();

Console.ReadKey();


其他代码不动,这样如果增加产品,我们只需要增加相应工厂,

这个已经能够满足SOLID原则的单一职责原则和对扩展开放,对修改封闭的原则。

ProductA

public class ProductA:Product
{
   public ProductA()
   {
       Console.WriteLine("ProductA created.");
   }
}

ProductB类似

抽象工厂模式将逻辑划分为产品层, 工厂层,抽象工厂层。这里我们得出一条结论:

if...else.switch这样的分支判断都是可以通过设计模式来分解的。


 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值