有两篇文章可以参考:
http://blog.csdn.net/column/details/design.html
http://www.cnblogs.com/jiese/tag/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/
软件领域中的设计模式为开发人员提供了一种使用专家设计经验的有效途径。设计模式中运用了面向对象编程语言的重要特性:封装、继承、多态,真正领悟设计模式的精髓是可能一个漫长的过程,需要大量实践经验的积累。最近看设计模式的书,对于每个模式,用C++写了个小例子,加深一下理解。主要参考《大话设计模式》和《设计模式:可复用面向对象软件的基础》两本书。本文介绍工厂模式的实现。
工厂模式属于创建型模式,大致可以分为三类,简单工厂模式、工厂方法模式、抽象工厂模式。听上去差不多,都是工厂模式。下面一个个介绍,首先介绍简单工厂模式,它的主要特点是需要在工厂类中做判断,从而创造相应的产品。当增加新的产品时,就需要修改工厂类。有点抽象,举个例子就明白了。有一家生产处理器核的厂家,它只有一个工厂,能够生产两种型号的处理器核。客户需要什么样的处理器核,一定要显示地告诉生产工厂。下面给出一种实现方案。
这样设计的主要缺点之前也提到过,就是要增加新的核类型时,就需要修改工厂类。这就违反了开放封闭原则:软件实体(类、模块、函数)可以扩展,但是不可修改。于是,工厂方法模式出现了。所谓工厂方法模式,是指定义一个用于创建对象的接口,让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。
听起来很抽象,还是以刚才的例子解释。这家生产处理器核的产家赚了不少钱,于是决定再开设一个工厂专门用来生产B型号的单核,而原来的工厂专门用来生产A型号的单核。这时,客户要做的是找好工厂,比如要A型号的核,就找A工厂要;否则找B工厂要,不再需要告诉工厂具体要什么型号的处理器核了。下面给出一个实现方案。
工厂方法模式也有缺点,每增加一种产品,就需要增加一个对象的工厂。如果这家公司发展迅速,推出了很多新的处理器核,那么就要开设相应的新工厂。在C++实现中,就是要定义一个个的工厂类。显然,相比简单工厂模式,工厂方法模式需要更多的类定义。
既然有了简单工厂模式和工厂方法模式,为什么还要有抽象工厂模式呢?它到底有什么作用呢?还是举这个例子,这家公司的技术不断进步,不仅可以生产单核处理器,也能生产多核处理器。现在简单工厂模式和工厂方法模式都鞭长莫及。抽象工厂模式登场了。它的定义为提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。具体这样应用,这家公司还是开设两个工厂,一个专门用来生产A型号的单核多核处理器,而另一个工厂专门用来生产B型号的单核多核处理器,下面给出实现的代码。
至此,工厂模式介绍完了。利用Rational Rose 2003软件,给出三种工厂模式的UML图,加深印象。
简单工厂模式的UML图:
工厂方法的UML图:
抽象工厂模式的UML图:
本人享有博客文章的版权,转载请标明出处 http://blog.csdn.net/wuzhekai1985
另一篇文章
转自http://blog.csdn.net/lh844386434/article/details/14518243
工厂模式是个系列,分为简单工厂模式, 工厂方法模式, 抽象工厂模式,这三种模式也非常常用。这些模式最最经典的就例子就是设计计算器。
简单工厂模式
严格的说,简单工厂模式并不是23种常用的设计模式之一,它只算工厂模式的一个特殊实现。简单工厂模式在实际中的应用相对于其他2个工厂模式用的还是相对少得多,因为它只适应很多简单的情况,最最重要的是它违背了我们在概述中说的开放-封闭原则。因为每次你要新添加一个功能,都需要在生switch-case 语句(或者if-else 语句)中去修改代码,添加分支条件。
简单工厂模式角色分配:
Creator(产品创建者)
简单工厂模式的核心,它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用,创建所需的产品对象。
Product ( 产品抽象类)
简单工厂模式所创建的所有对象的父类,它负责描述所有实例所共有的公共接口。
Concrete Product (具体产品)
是简单工厂模式的创建目标,所有创建的对象都是充当这个角色的某个具体类的实例。
简单工厂模式uml图:
考虑下面一个事例: 加入你是一个商人,你做的的是手机生意。现在你生产Android 手机和iphone等,考虑到以后你可能还会生产其他手机例如ubuntu手机。假定你选择了简单工厂模式来实现。那么显然,我们需要所有产品的抽象基类(Product) 即是Phone类:
然后我们需要具体的产品类 Concrete Product: AndroidPhone 和 IosPhone
最后我们需要Creator
客户端这样实现:
这就是简单工厂方法,把所有的创建交给creator,creator 通过switch-case(或者if-else)语句来选择具体创建的对象。简单明了。但是就如上面所说,它最致命的问题的违背了开放-封闭原则。每次你要新添加一个功能,都要修改factor里面的createPhone代码。 但是工厂方法模式可以解决这个问题。
工厂方法模式
具体工厂(Concrete Creator)角色:这是实现抽象工厂接口的具体工厂类,包含与应用程序密切相关的逻辑,并且受到应用程序调用以创建产品对象。
抽象产品(Product)角色:工厂方法模式所创建的对象的超类型,也就是产品对象的共同父类或共同拥有的接口。
具体产品(Concrete Product)角色:这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创建,它们之间往往一一对应。
上面这个和简单工厂方法还是一样的。接下来不一样的来了...
工厂方法将PhoneFactory抽象成了基类,PhoneFactory的createPhone不在像以前那样将所有的判断塞到里面。而是改由其子类来实现创建功能,这感觉就是权力下放。
抽象工厂模式
产品族: 在抽象工厂模式中,产品族是指由同一个工厂生产的,位于不同产品等级结构中的一组产品。比如分为android产品,和ios产品。其中一个ios产品包含ios手机和ios平板。显然ios手机和ios平板不是同一个产品等级结构的,因为一个是手机,一个是平板。但他们是同一个产品簇---都是ios产品。
抽象工厂模式的Uml 图:
然后具体的工厂我们整个工厂是生产移动设备的所以我们取名为MobileFactory,然后工厂可以生产平板和手机,故有了createPhone 和createPad两个接口。
接着是 android 产品簇 的工厂类,负责生产android 的手机和平板:
接着是ios的产品簇的工厂类,负责生产ios的手机和平板:
最后客户端这样实现:
总结: