关于设计模式,是一个永远说不完的也说不清的话题。毕竟在编程的世界里,没有最好的设计模式,只有最合适的设计模式。甚至有些时候,程序或者问题不到一定的规模,尝试所有的设计模式都是花架子。另外,在程序设计之初就谈论设计模式有些为时过早,但在问题出现之后才想起来设计模式却有为时已晚,毕竟后期代码的重构或者逻辑的优化都不是一件轻轻松松就能完成的事情。所以,在合适的地方在合适的时机使用合适的设计模式,恰好能体现出来一个开发者的优秀程度。 设计模式就像是武功的套路,每一个套路都有固定的招式。而每一个套路也不是万能的,不同的套路解决不同的问题。初学武功的人,只能以模仿的方式一招一式的练习,而大师级别的武术宗师心中却不受这些套路的桎梏。长时间的习武,反反复复的练习,早就把这些套路深深的印在了骨子里。必要的时候,就能不经思考的下意识出招。同理,深刻理解并经常应用设计模式的开发者,遇到问题的时候,可以熟练的筛选出来合适的设计模式。甚至有些时候,他们还可以把这些设计模式进行组合或者进行一些改造,来达到更好的效果,无招胜有招,心中无模式却胜过有模式,这大概就是设计模式的最高境界。
本篇文章要说的设计模式包括:简单工厂模式、工厂模式、抽象工厂模式。之所以把他们放到一起讲,因为这三个设计模式都属于创建型模式,即这三个设计模式都是为了解决对象的创建而生。把这三个设计模式拿来一起讲,可以更好的体现出来各自的优缺点。
简单工厂模式又叫做静态工厂方法,属于创建型模式。前面已经说过,简单工厂模式解决的是对象的创建问题,简单工厂模式主要由三个角色构成:工厂类、抽象产品类、具体产品类。
定义一个用于生产对象的类,封装生产不同的产品实例的细节,使创建对象的逻辑和客户端分离,客户端只需向这个类发起请求即可获得对应的产品实例,而无需关心对象的创建过程。 简单工厂模式解决的问题:客户端(此处的客户端指的是程序中使用产品类的某个类)根据不同的业务场景创建不同的产品对象的问题,而无需关心产品的的创建细节。 使用了简单工厂模式,客户端不需要增加创建产品类的代码,而创建产品类的代码被转移到了工厂类中,客户端通过调用工厂类的某个接口并且给这个接口传入对应的参数,就可以获得客户端需要的产品类的对象。这样的好处在于产品类的创建逻辑和客户端实现类分离,客户端不需要关心产品类的生产过程,只需要消费这个产品。
简单工厂模式
/// 简单工厂类
enum ProductEnum {
case ProductA
case ProductB
}
class SampleFactory: NSObject {
/// 注意这里是类方法,即静态方法,这就是静态工厂方法一名的由来
public class func product(product : ProductEnum) -> AbstractProduct {
switch product {
case .ProductA:
return ConcreteProductA()
case .ProductB:
return ConcreteProductB()
}
}
}
/// 抽象产品类:
class AbstractProduct: NSObject {
func interface() {
}
}
/// 具体产品类A
/// 继承自抽象产品类,覆写抽象产品类的相应接口
class ConcreteProductA: AbstractProduct {
override func interface() {
print("简单工厂模式:调用产品A实例方法")
}
}
/// 具体产品类B
/// 继承自抽象产品类,覆写抽象产品类的相应接口
class ConcreteProductB: AbstractProduct {
override func interface() {
print("简单工厂模式:调用产品B实例方法")
}
}
/// 客户端调用:
let facotry: SampleFactory = SampleFactory()
let productA: AbstractProduct = facotry.product(product: .ProductA)
productA.interface()
let productB: AbstractProduct = Factory.product(.ProductB)
productB.interface()
封装对象的创建过程,使创建对象的逻辑和客户端分离。 在简单工厂模式中,工厂类是整个模式的核心。在不使用简单工厂模式之前,如果我们要在客户端根据不同的场景创建不同的产品对象,我们就必须要写一些类似于if...else if...else...这样的条件分支语句。在使用了简单工厂模式后,原本属于客户端的逻辑判断代码,全部被转移到了工厂类内部。所以,工厂类代理了客户端的一部分逻辑判断功能。而客户端不再关心产品的具体创建细节,客户端只需要调用工厂类的指定接口,给这个接口传入不同的参数,工厂类就会根据客户端选择传递的参数动态实例化相关的类,然后给客户端返回一个实例化的对象。在这个模式中,工厂类负责“生产”对象,而客户端负责“消费”对象。工厂类和客户端明确了各自的职责和权利。
不符合开放-封闭原则。上面已经说过,在简单工厂模式中,把原本属于客户端的逻辑判断代码转移到了工厂类中,所以当需要增加或者删除某个产品类的时候,都需去工厂类中进行修改。这违反了编程中的开放封闭原则,即对扩展开放,对修改封闭。如果不明白:每增加一个产品类,都要去工厂类中增加对应的条件分支代码,这就是对修改开放了,所以违背了开放封闭原则。
一定要使用静态方法创建产品实例。工厂类中创建并返回产品实例的方法是类方法,即静态方法,这也是该模式的静态工厂方法别名的由来。所以,不要把这个方法写成对象方法。
1.客户端不需要关心或者不需要参与具体产品类的创建细节。 2.工厂类中创建的产品对象不是很多。 3.因为工厂类违背了开放-封闭原则,所以在工厂类不需要频繁改动、产品类不常变化的地方可以考虑使用该模式。
工厂方法模式经常被叫做工厂方法,和简单工厂模式一样,也是属于创建型模式。工厂方法模式由抽象工厂类、具体工厂类、抽象产品类、具体产品类4个类构成。
定义一个用于创建对象的接口,让子类决定实例化哪一个产品类,工厂方法使一个类的实例化延迟到其子类。
工厂方法模式
/// 抽象工厂类
// MARK:- 工厂类要实现的接口
protocol IFactory {
// 工厂类实现该接口用于生产产品实例,抽象工厂类实现该接口;具体工厂类重写该接口,返回具体的产品实例
func Manufacture() -> AbstractProduct;
}
// MARK:- 抽象工厂类
class AbstractFactory: NSObject,IFactory {
func Manufacture() -> AbstractProduct {
return AbstractProduct()
}
}
/// 抽象产品类
//MARK: 产品类需要实现的接口,抽象产品类实现该方法,具体产品类覆写该方法
protocol IProduct {
func operation()
}
// 抽象产品类
class AbstractProduct: NSObject,IProduct {
func operation() {
print("工厂方法模式:调用了抽象产品实现的接口")
}
}
/// 具体工厂类
class ConcreteFactoryA: AbstractFactory {
override func Manufacture() -> AbstractProduct {
return ConcreteProductA()
}
}
class ConcreteFactoryB: AbstractFactory {
override func Manufacture() -> AbstractProduct {
return ConcreteProductB()
}
}
/// 具体产品类
class ConcreteProductA: AbstractProduct {
override func operation() {
print("工厂方法模式:调用了产品A实现的接口")
}
}
class ConcreteProductB: AbstractProduct {
override func operation() {
print("工厂方法模式:调用了产品B实现的接口")
}
}
/// 客户端调用
let factoryA : AbstractFactory = ConcreteFactoryA()
let productA : AbstractProduct = factoryA.Manufacture()
productA.operation()
let factoryB : AbstractFactory = ConcreteFactoryB()
let productB : AbstractProduct = factoryB.Manufacture()
productB.operation()
工厂方法模式克服了简单工厂模式的缺点,即简单工厂模式违背的开放封闭原则。简单工厂模式的产品类和分支语句耦合,每增加一个产品类,就要去工厂类中增加相应的分支语句。而工厂方法模式抽象出来一个接口,这个接口就是创建抽象产品的工厂方法,这个接口由抽象工厂类实现,具体的工厂类进行覆写以生产不同的具体产品。以后我们再增加某个产品,只需要增加对应的具体工厂类和具体产品类。而无需修改原有的工厂类,这样就不会违背开放封闭原则。 工厂方法符合单一职责原则,即每一个具体的工厂类只负责生产一种具体的产品。
和简单工厂、工厂方法一样,抽象工厂模式也是一种创建型模式。和简单工厂工厂方法相比,抽象工厂更具有普遍性,更具有抽象性。和工厂方法一样,抽象工厂模式也是又由抽象工厂类、具体工厂类、抽象产品类、具体产品类4个类构成。
为创建一系列相关或相互依赖的对象提供一个接口,而且无需指定他们的具体的类。
抽象工厂模式
抽象工厂模式中有两个比较难以理解的概念,分别是产品树
(或产品系列)和产品簇
概念的。在抽象工厂模式中,有多少个抽象产品类,就有多少个产品树,因为抽象产品类和其衍生的若干个具体产品类在形式上组成了一个树状结构,所以称之为产品树。而不同的产品树中相互关联的产品组成了一个产品簇,一个具体的工厂类可以生产一个产品簇内的所有类型的产品实例。上面的UML中的ConcreteProductA1和ConcreteProductA2组成了一个产品簇,这个产品簇内的所有产品可以由ConcreteFacotory1来生产。同理,ConcreteProductA2和ConcreteProductB2组成了另一个产品簇,这个产品簇内的产品可以由ConcreteFactory2来生产。而抽象工厂模式是针对于产品簇这一概念的。因为每个具体工厂可以实例化多种产品实例。这些产品实例实际上是有一定关联的,或者说这些产品实例是有一定共同特点的。以下用使用苹果手机和诺基亚手机来举例说明产品树和产品簇的概念。
抽象工厂模式示例
上图中,苹果手机是一个产品系列(或称产品树),诺基亚手机是另一个产品系列。而苹果手机和诺基亚手机系列下都有5英寸和6英寸的手机,那么5英寸的苹果手机和5英寸的诺基亚手机就构成了一个产品簇。这个产品簇的产品可以由5InchFactory这个工厂来生产。
/// 抽象工厂类
protocol IFactory {
func createProductA() -> AbstractProductA
func createProductB() -> AbstractProductB
}
class AbstractFactory: NSObject, IFactory {
func createProductA() -> AbstractProductA {
return AbstractProductA()
}
func createProductB() -> AbstractProductB {
return AbstractProductB()
}
}
/// 抽象产品类A
protocol IProductA {
func operationA()
}
class AbstractProductA: NSObject, IProductA {
func operationA() {
}
}
/// 抽象产品类B
protocol IProductB {
func operationB()
}
class AbstractProductB: NSObject, IProductB {
func operationB() {
}
}
/// 具体工厂类1
class ConcreteFactory1: AbstractFactory {
func createProductA() -> AbstractProductA {
return ConcreteProductA1()
}
func createProductB() -> AbstractProductB {
return ConcreteProductB1()
}
}
/// 具体工厂类2
class ConcreteFactory2: AbstractFactory {
func createProductA() -> AbstractProductA {
return ConcreteProductA2()
}
func createProductB() -> AbstractProductB {
return ConcreteProductB2()
}
}
/// 具体产品类A1
class ConcreteProductA1: AbstractProductA {
override func operationA() {
print("调用了ConcreteProductA1的接口")
}
}
/// 具体产品类A2
class ConcreteProductA2: AbstractProductA {
func operationA() {
print("调用了ConcreteProductA2的接口")
}
}
/// 具体产品类B1
class ConcreteProductB1: AbstractProductB {
override func operationB() {
print("调用了ConcreteProductB1的接口")
}
}
/// 具体产品类B2
class ConcreteProductB2: AbstractProductB {
override func operationB() {
print("调用了ConcreteProductB2的接口")
}
}
/// 客户端调用
let factory1 = ConcreteFactory1()
let productA1 = factory1.createProductA()
let productB1 = factory1.createProductB()
productA1.operationA()
productB1.operationB()
let factory2 = ConcreteFactory2()
let productA2 = factory2.createProductA()
let productB2 = factory2.createProductB()
productA2.operationA()
productB2.operationB()
工厂方法模式的定义是:定义一个用于创建对象的接口,让子类决定实例化哪一个产品类,工厂方法使一个类的实例化延迟到其子类。抽象工厂的定义是:为创建一系列相关或相互依赖的对象提供一个接口,而且无需指定他们的具体的类。
从UML类图中,不难看出,抽象工厂模式和工厂方法模式是非常相似的,只不过抽象工厂模式比工厂方法模式多了一些抽象类和具体的产品类。这就是他们的区别所在。二者的区别在于:工厂方法的产品类单一,工厂方法有一个抽象工厂类和一个抽象产品类,有若干个具体工厂类和具体产品类,每一个具体的工厂类都对应一个具体产品类。每种具体工厂类只能实例化一种具体产品类。所以具体的工厂类和具体的产品类的个数是相等的。而抽象工厂模式是针对于解决多个系列的产品而诞生的。即在抽象工厂模式中,抽象产品不止有一种。如果我们把一种抽象产品比作成一个产品系列(或者比作一棵产品树),那么抽象工厂模式下会有多个系列(或多棵产品树)。每个产品系列下又有包括多种不同类型的产品。以下是工厂方法模式和抽象工厂的比对:
工厂方法模式 | 抽象工厂模式 |
---|---|
定义一个用于创建对象的接口,让子类决定实例化哪一个产品类,工厂方法使一个类的实例化延迟到其子类。 | 为创建一系列相关或相互依赖的对象提供一个接口,而且无需指定他们的具体的类。 |
针对一个产品树 | 针对多个产品树 |
一个抽象产品类 | 多个抽象产品类 |
可以派生出多个具体产品类 | 每个抽象产品类可以派生出多个具体产品类 |
每个具体工厂类只能创建 一种 具体产品类的实例 | 每个具体工厂类可以创建 多种具体产品类的实例(至于多少种,取决于有多少个产品树) |
// 如果从产品1切换到产品2,那么只需要把下面初始化factory1改为初始化factory2即可,其他地方无需改动。
// let factory1 = ConcreteFactory1()
let factory2 =ConcreteFactory2()
let productA = factory1.createProductA()
let productB = factory1.createProductB()
抽象工厂模式中,侧重的是工厂类也就是产品簇,而非产品类。
抽象工厂模式-与-工厂方法模式区别 《大话设计模式》
文/VV木公子(简书作者) PS:如非特别说明,所有文章均为原创作品,著作权归作者所有,转载请联系作者获得授权,并注明出处。