分享

设计模式学习笔记(三)——Abstract Factory抽象工厂模式

 skywood 2007-08-06

     抽象工厂是一种创建型模式,是为了解决实例化时所带来的问题。
     我们先来看看是什么问题,有的时候我们会遇到这种情况,我们需要一系列的对象。举个例子,有一系列BMW汽车零部件的对象:轮子bmwwheel,油箱bmwoilbox,在一个管理函数中调用它们,代码如下
class BMWWheel
{
 public BMWWheel(){};

class BMWOilbox
{
 public BMWOilbox(){};
}
public void Manage()
{
 BMWOilbox oilbox = new BMWOilbox();
 BMWWheel wheel = new BMWWheel();
}
    如果现在需求变了,我们要用大众一汽BORA的零件,不用BMW的,那么我们除了要再加上相应的零件对象外还要将Manage函数中的对象更改为BORA的零件对象。
     那这时发现new会带来了一些问题:实现依赖,不能应对具体实例化类型的变化。
     如何解决这类问题呢?封装变化点。(没有变化的就不需要封装)
     工厂模式的缘起:
          1、变化点在“对象创建”,因此就封装“对象创建”
          2、面向接口编程
     简单工厂问题:
      1、不能应对“不同系列对象”的变化。如:我们要在上面的代码中加上其他的对象就不能很好的应对了
      2、使用面向对象国内的技术来封装变化点
     动机:在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;同时,由于需求的变化,往往存在更多系列对象的创建工作。面对这种问题,我们想绕过常规的对象创建方法,提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合。
     对于“紧耦合”,我原来是不喜欢这个词的,但是今天明白了,不是程序紧耦合不好,而是面对频繁变化的需求,紧耦合会使程序的编写变得很吃力。如果面对一个不变的需求,松耦合和紧耦合在代码编写上应该是没什么区别的。
     《设计模式》中解释这种模式的意图是:提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定他们的具体类。
     下面我们来看看如何使用抽象工厂模式完成对这种变化的封装:
     首先我们的需求是BMW的车轮和油箱,当然他们要继承各自的基类,代码如下

 abstract class AbstractWheel
 {
  public AbstractWheel()
  {
   //Console.Write("Create a AbstractProduct");
  }
 }

 abstract class AbstractOilBox
 {
  public AbstractOilBox()
  {}
 }

 class BMWWheel:AbstractWheel
 {
  public BMWWheel()
  {
   Console.Write("Create a BMWwheel");
  }
 }

 class BMWOilBox:AbstractOilBox
 {
  public BMWOilBox()
  {
   Console.Write("Create a BMWOilBox");
  }
 }
 
     然后,我们在建立一个生产这些零件的工厂,它继承自一个抽象工厂

 //抽象工厂
 abstract class AbstractFactory
 {
  abstract public AbstractWheel CreatWheel();
  abstract public AbstractOilBox CreatOilBox();
 }

 class BMWFactory:AbstractFactory
 {
  public override AbstractWheel CreatWheel()
  {
   return new BMWWheel();
  }

  public override AbstractOilBox CreatOilBox()
  {
     return new BMWOilBox();
  }

 }

     现在我们在Main函数中调用它们:
 static void Main(string[] args)
  {
   AbstractFactory factory = null;
   factory = new BMWFactory();
   factory.CreatWheel();
   Console.Write("\n");
   factory.CreatOilBox();
   Console.Write("\n");
   Console.Read();
  }
     显示结果:
          Create a BMWwheel
          Create a BMWOilBox

     现在我们想不用BMW的零件,用BORA的零件了,先写一些BORA零件的类:
 class BORAWheel:AbstractWheel
 {
  public BORAWheel()
  {
   Console.Write("Create a BORAWheel");
  }
 }

 class BORAOilBox:AbstractOilBox
 {
  public BORAOilBox()
  {
   Console.Write("Create a BORAOilBox");
  }
 }
     然后我们再创建BORA零件的工厂:
 class BORAFactory:AbstractFactory
 {
  public override AbstractWheel CreatWheel()
  {
   return new BORAWheel();
  }

  public override AbstractOilBox CreatOilBox()
  {
   return new BORAOilBox();
  }

 }
     再来看看如何在Main函数中修改使其调用BORA的零件;我们只要在将Main中的factory对象实例化为BORA的工厂BORAFactory就可以了:
 static void Main(string[] args)
  {
   AbstractFactory factory = null;
   factory = new BORAFactory();
   factory.CreatWheel();
   Console.Write("\n");
   factory.CreatOilBox();
   Console.Write("\n");
   Console.Read();
  }
 
     结果如下:
          Create a BORAWheel
          Create a BORAOilBox


 
     Abstract Factory模式的几个要点:
          1、如果没有应对“多系列对象构建”的需求变化,则没有必要使用Abstract Factory模式。
          2、“系列对象”指的是这项对象之间有相互依赖、或作用的关系。
          3、Abstract Factory模式主要在于应对“新系列”的需求变动。缺点是难以应对“新对象”的需求变动。这一点应该注意,就像前面说的,如果我们现在要在加入其他系列的类,代码的改动会很大。
          4、Abstract Factory模式经常和Factory Method模式共同组合来应对“对象创建”的需求变化。

posted on 2006-04-22 22:37 KiddLee 阅读(1367) 评论(8)  编辑 收藏 引用 网摘 所属分类: 设计模式

FeedBack:
# 
工厂模式一搜一堆
而且为什么不用UML来表示呢?
代码看起来太乱  回复  更多评论
  
# re: 设计模式学习笔记(三)——Abstract Factory抽象工厂模式  2006-04-23 18:01 共享精神
楼上的话是不是太绝对了?
baidu上确实是一搜一片~
但是,不知道,不懂的还有很多,每年都有新的程序员在成长,难不成他们不看都懂?
别的不想多说,共享的精神才是程序员应有的.
帮楼主顶了  回复  更多评论
  
# re: 设计模式学习笔记(三)——Abstract Factory抽象工厂模式  2006-04-23 21:18 kid_li
哈哈,谢了,的确设计模式很早就有了,我也是学习了一些共享的资料后,把我的理解写上去,如果大家愿意看看,和我讨论一下,共同进步一下。我以后也考虑一下使用UML表示。还望多多指点  回复  更多评论
  
# re: 设计模式学习笔记(三)——Abstract Factory抽象工厂模式  2006-04-28 12:39 bisou.cn
怎么不继续写了呢!关注中  回复  更多评论
  
# re: 设计模式学习笔记(三)——Abstract Factory抽象工厂模式  2006-04-28 13:15 kid_li
@bisou.cn
哈哈,谢谢大家的关注,这几天就写  回复  更多评论
  
# re: 设计模式学习笔记(三)——Abstract Factory抽象工厂模式  2006-06-22 17:04 Oscar
3、Abstract Factory模式主要在于应对“新系列”的需求变动。缺点是难以应对“新对象”的需求变动。这一点应该注意,就像前面说的,如果我们现在要在加入其他系列的类,代码的改动会很大。
-------------------------------------
其实是这样的,“新对象”变化指的是AbstractWheel的接口增加,那么代码修改量就会很大,而不是增加其他系列的类。
  回复  更多评论
  
# re: 设计模式学习笔记(三)——Abstract Factory抽象工厂模式  2006-07-11 11:35 大雁
这篇文章写得不错,通俗易懂,我看了篇关于抽象工厂模式的文章,都不是很理解,看了这篇,思维一下子明朗。如果作者能在文中附加UML图,效果会更好。  回复  更多评论
  
# re: 设计模式学习笔记(三)——Abstract Factory抽象工厂模式  2007-03-20 15:07 反洗钱系统
楼上的真会说话啊~~!!
谢谢楼主的文章!  回复  更多评论
  

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多