3种工厂模式

用户故事:
在系统中存在user用户表,对user表有增删改查操作,对于选用不同的数据库,在创建连接,具体的SQL操作各有所不同。系统在后续维护过程中可能会更换其他数据库,为了在面对后期可能更改数据库的需求,如何避免在后期更换数据库的时候产生的代价较小呢?

一个抽象产品会有不同的具体产品,如车这类抽象产品会有汽车,卡车等。当我们在使用不同车的时候,按照最直观的写法:客户端什么地方使用到对应的车,就通过new的方式去创建实例。这样虽然写起来简便,但是客户端和具体的车的就耦合在了一起,当修改了具体的车的类的时候,我们可能需要将整个项目中全部用到new的地方都进行修改。

为了降低这种耦合,可以建立一个工厂来创建对象。把创建的过程和细节封装到工厂里。客户端直接使用工厂来创建实例,并且具体创建实例的过程,客户端可能并不是很关注。

简单工厂模式

最简单、最直观的工厂模式。

提供一个工厂类,在工厂类中提供一个公共的方法用于返回特定的对象实例,也就是说在方法中会存在相应的逻辑判断(switch或if)分支,以实现可以返回不同的对象实例。

UML图:

缺点:如果后期需要创建新的或删除不存在对象实例,都需要修改工厂类,这样工厂类很被动。
改进:在所有使用简单工厂的地方,都可以考虑使用反射技术来去除switch或if,解除分支判断带来的耦合。

工厂方法模式

定义:
定义一个用于创建对象实例的接口,让其子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

UML图:

工厂方法 VS 简单工厂

工厂方法模式和简单工厂的区别在于:简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断,根据客户端的选择动态实例化相关的类,对于客户端来说,去除了与具体产品的依赖。但是问题也正是在这里:简单工厂在新增或者去除对象实例的时候却要修改原有的工厂类(在工厂类中增加或删除逻辑分支),这样就等于不但对扩展开放,对修改也开放了。这样就违背了开放-扩展原则。
工厂方法模式实现时,客户端需要决定实例化哪一个工厂来实现具体的产品类,选择判断的问题还是存在的,也就是说,工厂方法把简答工厂的内部逻辑判断移动到了客户端代码来进行。想要增加产品新的实现类,简单工厂需要修改工厂类,工厂方法需要新增加具体的工厂类。

优点:
工厂方法模式克服了简单工厂违背开放-封闭原则的缺点,又保持了封装对象创建过程的优点。
当需要增加抽象产品新的实现类时,不需要修改抽象工厂接口,只需要增加对应的产品实现类和工厂类即可。
工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性,工厂方法模式保持了简单工厂模式的优点,且克服了它的缺点。
缺点:
当需要增加产品新的实现类时,就需要增加一个对应工厂的类,增加了额外的开发量。

适用场景:
只有一种需要扩展的抽象类时,使用工厂方法可以比较方便。
对应开始数据库的例子,如果系统中只有user表,面对使用不同数据情况时,可以通过工厂方法模式实现在不同数据库下的对User表操作的实例。
当系统中增加Department表时,也就是多了另外一种需要扩展的抽象类,这时又需要如何实现?

抽象工厂模式

定义:
提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
抽象工厂模式其实就是工厂方法模式的进一步扩展,工厂方法模式中工厂接口只提供创建一种产品对象,而抽象工厂模式中抽象接口提供创建一个系列对象。

UML图:

AbstractProductA和AbstractProductB是两个抽象产品,之所有抽象,是因为它们都有可能有不同的实现,如User表和Department表,在不同的数据库下有不同的增删改查操作细节,ProductA1和ProductB1可以理解为同一种数据下的操作实现

IFactory是一个抽象工厂接口,它里面应该包含所有的抽象产品创建的抽象方法,而ConcreteFactory1和ConcreteFactory2就是具体的工厂。

通常是在运行时刻再创建一个具体的工厂类的实例,这个具体的工厂再创建具有特定实现的产品对像,也就是说,为创建不同的产品对象,客户端应使用不同的具体工厂。

优点:
(1)最大的好处便于交换产品系列,由于具体工厂类,例如IFactory factory = new AddOperation(),在一个应用中只需要在初始的时候出现一次,这就使得改变一个应用的具体工厂变得非常容易,它只需要改变具体工厂即可使用不同的产品配置。我们的设计不能防止需求的更改,那么最理想的便是让改动变得最小;
(2)它让具体的创建实例过程与客户端代码分离,客户端是通过他们的抽象接口操纵实例,产品的具体类名也被具体的工厂实现分离,不会出现在客户代码中。
缺点:
如果增加其他产品的情况下改动是比较大的,因为不仅需要在抽象工厂接口中新增工厂方法,还需要在已经实现的具体工厂子类中新增对应的工厂方法。
改进:
使用通过反射方式加强的简单工厂模式来避免当新增产品实例时所带来的改动。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值