23种设计模式之---抽象工厂模式(Abstract Factory)

本文深入探讨了抽象工厂模式,一种创建型设计模式,用于创建一系列相关或相互依赖的对象,而无需指定具体类。分析了其结构,展示了如何通过具体工厂轻松更换产品系列,以及模式在数据库切换等场景的应用。

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

1.抽象工厂模式(创建型模式)

提供了一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。

2.抽象工厂的结构图及分析

分析:

AbstractProductAAbstractProductB是两个抽象产品,之所以为抽象,是因为它们都有可能有两种不同的实现,而ProductA1,ProductA2,ProductB1,ProductB2就是对两个抽象产品的具体分类的实现。AbstractFactory是一个抽象工厂接口,它里面应该包含所有的产品创建的抽象方法。而ConcreteFactory1ConcreteFactory2就是具体的工厂了.通常是在运行时刻再创建一个ConcreteFactory类的实例,这个具体的工厂再创建具有指定实现的产品对象,也就是说,为创建不同的产品对象,客户端应使用不同的具体工厂。

3.抽象工厂模式的优点与缺点

最大的好处便是易于交换产品系列,由于具体工厂类,例如IFactory factory = new ConcreteFactory(),在一个应用中只需要在初始化的时候出现一次,这就使得改变一个应用的具体工厂变得非常容易,它只需要改变具体工厂即可使用不同的产品配置。我们的设计不能去防止需求的更改,那么理想的是让改动变得最小,现在如果你要更改数据库访问,我们只需要更改具体工厂就可以做到。第二大好处是,它让具体的创建实例过程与客户端分离,客户端通过它们的抽象接口操纵实例,产品的具体类名也被具体工厂的实现分离,不会出现在客户端代码中。

抽象工厂模式把开闭原则和依赖倒转原则发挥到极致。

缺点是想添加一个新模块同时要增加三个类,还需要更改三个类。

4.使用反射+配置文件的方式优化抽象工厂

使用反射+抽象工厂模式可以解决代码的可维护以及可扩展的问题。从这个角度上来说,所有用简单工厂的地方,都可以考虑用反射技术来去除实例化相关(具体实例化那个产品)的逻辑判断,解除分支判断带来的耦合。

应用场景: 数据库的切换

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值