设计模式—工厂三姐妹

简单工厂模式

简单工厂模式是属于创建型模式,又称静态工厂方法模式。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。

简单工厂模式专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。

简单工厂模式是工厂模式家族中最简单实用的模式,可以理解为是不同工厂模式的一个特殊实现。

实质

是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类(这些产品类继承自一个父类或接口)的实例。

简单工厂模式结构

角色

类别

说明

Product

产品类

一般是一个抽象类或是接口

ConcreteProduct

具体的产品类

实现或是继承Product

Factory

工厂类

用来创建具体的产品

优点

简单工厂模式的最大优点在于工程类中包含了必要的逻辑判断,根据客户端的选择条件动态实例化相关的类,对于客户端来说,去除了与具体产品的依赖。

缺点

简单工厂模式不遵循开闭原则,一旦添加新产品就不得不修改工厂逻辑,在产品类型较多时,有可能造成工厂逻辑过于复杂,不利于系统的扩展和维护。

使用简单工厂模式将会增加系统中类的个数,在一定程序上增加了系统的复杂度和理解难度,对系统的维护和扩展非常不利。

简单工厂模式-UML结构图

个人理解

其中的工厂对象很关键,简单工厂就是由客户端输入选择条件,工厂类根据传入的参数,动态决定应该创建哪一个产品类的实例。

工厂方法模式

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

其中,核心结构有四个角色,分别是抽象工厂、具体工厂、抽象产品、具体产品。

抽象工厂(Creator)角色:是工厂方法模式的核心,与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。

具体工厂(Concrete Creator)角色:这是实现抽象工厂接口的具体工厂类,包含与应用程序密切相关的逻辑,并且受到应用程序调用以创建产品对象。

抽象产品(Product)角色:工厂方法模式所创建的对象的超类型,也就是产品对象的共同父类或共同拥有的接口。

具体产品(Concrete Product)角色:这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创建,它们之间往往一一对应。

优点

工厂类中包含了必要的逻辑判断,根据客户端的选择条件动态实例化相关的类,对于客户端来说,去除了与具体产品的依赖。

在系统中添加产品时,无须修改抽象工厂和抽象产品提供的接口,无须修改客户端,也无须修改其他的具体工厂和具体产品,而只要添加一个具体工厂和具体产品就可以了。这样,系统的可扩展性也就变得非常好,完全符合“开闭原则”。

缺点

在添加新产品时,需要编写新的具体产品类,而且还要提供与之对应的具体工厂类,系统中类的个数将成对增加,在一定程度上增加了系统的复杂度,有更多的类需要编译和运行,会给系统带来一些额外的开销。

工厂方法模式-UML结构图

工厂方法模式实现时,客户端需要决定实例化哪一个工厂来实现运算类,选择判断的问题还是存在的,也就是说,工厂方法把简单工厂的内部逻辑判断移到了客户端代码来运行。你想要加功能,本来是改工厂类的,而现在是修改客户端。

抽象工厂模式

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

优点

易于交换产品系列,由于具体工厂类,在一个应用中只需在初始化时出现一次,这就使得改变一个应用的具体工厂变得很容易,它只需要改变具体工厂即可使用不同的产品配置。

它让具体的创建实例过程与客户端分离,客户端是通过他们抽象接口操纵实例,产品的具体类名也被具体工厂的实现分离,不会出现在客户代码中。

缺点

增加新的产品等级结构很复杂,需要修改抽象工厂和所有的具体工厂类,对“开闭原则”的支持呈现倾斜性。

抽象工厂模式-UML结构图

IDepartment接口,用于客户端访问,解除与具体数据库访问的耦合。

评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值