First we try, then we trust

  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  183 随笔 :: 111 文章 :: 3187 评论 :: 358 引用

一、 建造者(Builder)模式

建造者模式可以将一个产品的内部表象与产品的生成过程分割开来,从而可以使一个建造过程生成具有不同的内部表象的产品对象。

对象性质的建造

有些情况下,一个对象会有一些重要的性质,在它们没有恰当的值之前,对象不能作为一个完整的产品使用。比如,一个电子邮件有发件人地址、收件人地址、主题、内容、附录等部分,而在最起码的收件人地址未被赋值之前,这个电子邮件不能发出。

有些情况下,一个对象的一些性质必须按照某个顺序赋值才有意义。在某个性质没有赋值之前,另一个性质则无法赋值。这些情况使得性质本身的建造涉及到复杂的商业逻辑。

这时候,此对象相当于一个有待建造的产品,而对象的这些性质相当于产品的零件,建造产品的过程就是组合零件的过程。由于组合零件的过程很复杂,因此,这些"零件"的组合过程往往被"外部化"到一个称作建造者的对象里,建造者返还给客户端的是一个全部零件都建造完毕的产品对象。

命名的考虑

之所以使用"建造者"而没有用"生成器"就是因为用零件生产产品,"建造"更为合适,"创建"或"生成"不太恰当。


二、 Builder模式的结构:

 

建造者(Builder)角色:给出一个抽象接口,以规范产品对象的各个组成成分的建造。一般而言,此接口独立于应用程序的商业逻辑。模式中直接创建产品对象的是具体建造者(ConcreteBuilder)角色。具体建造者类必须实现这个接口所要求的方法:一个是建造方法,另一个是结果返还方法。

具体建造者(Concrete Builder)角色:担任这个角色的是于应用程序紧密相关的类,它们在应用程序调用下创建产品实例。这个角色主要完成的任务包括:

  • 实现Builder角色提供的接口,一步一步完成创建产品实例的过程。
  • 在建造过程完成后,提供产品的实例。

指导者(Director)角色:担任这个角色的类调用具体建造者角色以创建产品对象。导演者并没有产品类的具体知识,真正拥有产品类的具体知识的是具体建造者对象。

产品(Product)角色:产品便是建造中的复杂对象。

指导者角色是于客户端打交道的角色。导演者角色将客户端创建产品的请求划分为对各个零件的建造请求,再将这些请求委派给具体建造者角色。具体建造者角色是做具体建造工作的,但却不为客户端所知。


三、 程序举例:

该程序演示了Builder模式一步一步完成构件复杂产品的过程。用户可以控制生成过程以及生成不同对象。

// Builder pattern -- Structural example  

using System;
using System.Collections;

// "Director"
class Director
{
  
// Methods
  public void Construct( Builder builder )
  
{
    builder.BuildPartA();
    builder.BuildPartB();
  }

}


// "Builder"
abstract class Builder
{
  
// Methods
  abstract public void BuildPartA();
  
abstract public void BuildPartB();
  
abstract public Product GetResult();
}


// "ConcreteBuilder1"
class ConcreteBuilder1 : Builder
{
  
// Fields
  private Product product;

  
// Methods
  override public void BuildPartA()
  
{
    product 
= new Product();
    product.Add( 
"PartA" );
  }


  
override public void BuildPartB()
  
{
    product.Add( 
"PartB" );
  }


  
override public Product GetResult()
  
{
    
return product;
  }

}


// "ConcreteBuilder2"
class ConcreteBuilder2 : Builder
{
  
// Fields
  private Product product;

  
// Methods
  override public void BuildPartA()
  
{
    product 
= new Product();
    product.Add( 
"PartX" );
  }


  
override public void BuildPartB()
  
{
    product.Add( 
"PartY" );
  }


  
override public Product GetResult()
  
{
    
return product;
  }

}


// "Product"
class Product
{
  
// Fields
  ArrayList parts = new ArrayList();
 
  
// Methods
  public void Add( string part )
  
{
    parts.Add( part );
  }


  
public void Show()
  
{
    Console.WriteLine( 
" Product Parts -------" );
    
foreachstring part in parts )
      Console.WriteLine( part );
  }

}


/// <summary>
/// Client test
/// </summary>

public class Client
{
  
public static void Main( string[] args )
  
{
    
// Create director and builders
    Director director = new Director( );

    Builder b1 
= new ConcreteBuilder1();
    Builder b2 
= new ConcreteBuilder2();

    
// Construct two products
    director.Construct( b1 );
    Product p1 
= b1.GetResult();
    p1.Show();

    director.Construct( b2 );
    Product p2 
= b2.GetResult();
    p2.Show();
  }

}



四、 建造者模式的活动序列:

客户端负责创建指导者和具体建造者对象。然后,客户把具体建造者对象交给指导者。客户一声令下,指导者操纵建造者开始创建产品。当产品创建完成后,建造者把产品返还给客户端。


五、 建造者模式的实现:

下面的程序代码演示了Shop对象使用VehicleBuilders来建造不同的交通工具。该例子使用了Builder模式顺序建造交通工具的不同部分。

// Builder pattern -- Real World example  

using System;
using System.Collections;

// "Director"
class Shop
{
  
// Methods
  public void Construct( VehicleBuilder vehicleBuilder )
  
{
    vehicleBuilder.BuildFrame();
    vehicleBuilder.BuildEngine();
    vehicleBuilder.BuildWheels();
    vehicleBuilder.BuildDoors();
  }

}


// "Builder"
abstract class VehicleBuilder
{
  
// Fields
  protected Vehicle vehicle;

  
// Properties
  public Vehicle Vehicle
  
{
    
getreturn vehicle; }
  }


  
// Methods
  abstract public void BuildFrame();
  
abstract public void BuildEngine();
  
abstract public void BuildWheels();
  
abstract public void BuildDoors();
}


// "ConcreteBuilder1"
class MotorCycleBuilder : VehicleBuilder
{
  
// Methods
  override public void BuildFrame()
  
{
    vehicle 
= new Vehicle( "MotorCycle" );
    vehicle[ 
"frame" ] = "MotorCycle Frame";
  }


  
override public void BuildEngine()
  
{
    vehicle[ 
"engine" ] = "500 cc";
  }


  
override public void BuildWheels()
  
{
    vehicle[ 
"wheels" ] = "2";
  }


  
override public void BuildDoors()
  
{
    vehicle[ 
"doors" ] = "0";
  }

}


// "ConcreteBuilder2"
class CarBuilder : VehicleBuilder
{
  
// Methods
  override public void BuildFrame()
  
{
    vehicle 
= new Vehicle( "Car" );
    vehicle[ 
"frame" ] = "Car Frame";
  }


  
override public void BuildEngine()
  
{
    vehicle[ 
"engine" ] = "2500 cc";
  }


  
override public void BuildWheels()
  
{
    vehicle[ 
"wheels" ] = "4";
  }


  
override public void BuildDoors()
  
{
    vehicle[ 
"doors" ] = "4";
  }

}


// "ConcreteBuilder3"
class ScooterBuilder : VehicleBuilder
{
  
// Methods
  override public void BuildFrame()
  
{
    vehicle 
= new Vehicle( "Scooter" );
    vehicle[ 
"frame" ] = "Scooter Frame";
  }


  
override public void BuildEngine()
  
{
    vehicle[ 
"engine" ] = "none";
  }


  
override public void BuildWheels()
  
{
    vehicle[ 
"wheels" ] = "2";
  }


  
override public void BuildDoors()
  
{
    vehicle[ 
"doors" ] = "0";
  }

}


// "Product"
class Vehicle
{
  
// Fields
  private string type;
  
private Hashtable parts = new Hashtable();

  
// Constructors
  public Vehicle( string type )
  
{
    
this.type = type;
  }


  
// Indexers
  public object thisstring key ]
  
{
    
getreturn parts[ key ]; }
    
set{ parts[ key ] = value; }
  }


  
// Methods
  public void Show()
  
{
    Console.WriteLine( 
" ---------------------------");
    Console.WriteLine( 
"Vehicle Type: "+ type );
    Console.WriteLine( 
" Frame : " + parts[ "frame" ] );
    Console.WriteLine( 
" Engine : "+ parts[ "engine"] );
    Console.WriteLine( 
" #Wheels: "+ parts[ "wheels"] );
    Console.WriteLine( 
" #Doors : "+ parts[ "doors" ] );
  }

}


/// <summary>
/// BuilderApp test
/// </summary>

public class BuilderApp
{
  
public static void Main( string[] args )
  
{
    
// Create shop and vehicle builders
    Shop shop = new Shop();
    VehicleBuilder b1 
= new ScooterBuilder();
    VehicleBuilder b2 
= new CarBuilder();
    VehicleBuilder b3 
= new MotorCycleBuilder();

    
// Construct and display vehicles
    shop.Construct( b1 );
    b1.Vehicle.Show();

    shop.Construct( b2 );
    b2.Vehicle.Show();

    shop.Construct( b3 );
    b3.Vehicle.Show();
  }

}


六、 建造者模式的演化

建造者模式在使用的过程中可以演化出多种形式。

省略抽象建造者角色

如果系统中只需要一个具体建造者的话,可以省略掉抽象建造者。这时代码可能如下:

// "Director"
class Director
{
  
private ConcreteBuilder builder;

  
// Methods
  public void Construct()
  
{
    builder.BuildPartA();
    builder.BuildPartB();
  }

}


省略指导者角色

在具体建造者只有一个的情况下,如果抽象建造者角色已经被省略掉,那么还可以省略掉指导者角色。让Builder角色自己扮演指导者与建造者双重角色。这时代码可能如下:

public class Builder
{
  
private Product product = new Product();

  
public void BuildPartA()
  

    
//Some code here
  }


  
public void BuildPartB()
  
{
    
//Some code here
  }


  
public Product GetResult()
  
{
    
return product;
  }


  
public void Construct()
  
{
    BuildPartA();
    BuildPartB();
  }

}

同时,客户端也需要进行相应的调整,如下:

public class Client
{
  
private static Builder builder;

  
public static void Main()
  
{
    builder 
= new Builder();
    builder.Construct();
    Product product 
= builder.GetResult();
  }

}

C#中的StringBuilder就是这样一个例子。


七、 在什么情况下使用建造者模式

以下情况应当使用建造者模式:

1、 需要生成的产品对象有复杂的内部结构。
2、 需要生成的产品对象的属性相互依赖,建造者模式可以强迫生成顺序。
3、 在对象创建过程中会使用到系统中的一些其它对象,这些对象在产品对象的创建过程中不易得到。

使用建造者模式主要有以下效果:

1、 建造模式的使用使得产品的内部表象可以独立的变化。使用建造者模式可以使客户端不必知道产品内部组成的细节。
2、 每一个Builder都相对独立,而与其它的Builder无关。
3、 模式所建造的最终产品更易于控制。


参考文献:
阎宏,《Java与模式》,电子工业出版社
[美]James W. Cooper,《C#设计模式》,电子工业出版社
[美]Alan Shalloway  James R. Trott,《Design Patterns Explained》,中国电力出版社
[美]Robert C. Martin,《敏捷软件开发-原则、模式与实践》,清华大学出版社
[美]Don Box, Chris Sells,《.NET本质论 第1卷:公共语言运行库》,中国电力出版社

0
0
(请您对文章做出评价)
« 上一篇:C#设计模式(7)-Singleton Pattern
» 下一篇:C#设计模式(8)-Builder Pattern
posted on 2004-08-29 01:31 吕震宇 阅读(21451) 评论(41)  编辑 收藏 网摘 所属分类: 设计模式

评论

好文
支持

  回复  引用    

#2楼 2004-08-31 22:55 happyfool
老大怎么没有发表新的文章?
期待中。。。。

  回复  引用    

#3楼 2004-09-01 08:08 吕震宇
最近比较忙,有一个新项目在做,所以恐怕文章发表进度要慢一些,不过我会写完它的!
  回复  引用    

#4楼 2004-09-04 21:37 wayfarer
同样是生成产品,工厂模式是生产某一类产品,而builder模式则是将产品的零件按某种生产流程组装起来。因此两者是有区别的,文章中的示例表示得很清楚了。

例如我们将文中的VehicleBuilder改为VehicleFactory,那么该抽象类的方法应该就只有CreateVehicle()方法了,它不会理会Frame、Engine等部件的创建,此时Vehicle应是一个整体。

那么在具体的工厂类中,例如MotorFactory类,生产产品的方法应该就是:
public Vehicle CreateVehicle()
{
return new Motor();
}

在现实世界中,选择使用工厂模式,还是使用Builder模式,容易混淆,不过文中给出了好的建议,收获颇多。

  回复  引用    

#5楼 2004-09-04 22:23 吕震宇
实际上,有些时候两者是结合使用的。我见过BuilderFactory。在Java的DOM模型中就使用了BuilderFactory。

Java 环境中,解析文件是一个三步过程:

1、创建 DocumentBuilderFactory。 DocumentBuilderFactory 对象创建 DocumentBuilder。
2、创建 DocumentBuilder。 DocumentBuilder 执行实际的解析以创建 Document 对象。
3、解析文件以创建 Document 对象。

关键代码如下:

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import java.io.File;
import org.w3c.dom.Document;

public class OrderProcessor {
public static void main (String args[]) {
File docFile = new File("orders.xml");
Document doc = null;
try {

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
doc = db.parse(docFile);

} catch (Exception e) {
System.out.print("Problem parsing the file: "+e.getMessage());
}
}
}

很有创意的!

  回复  引用    

#6楼 2004-09-04 22:27 吕震宇
续:

我们可以给工厂“下订单”,决定生产什么样子的Builder:

try {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

dbf.setValidating(true);

DocumentBuilder db = dbf.newDocumentBuilder();
doc = db.parse(docFile);
} catch (Exception e) {

其中dbf.setValidating(true);命令就是控制工厂的生产方式,这样建造出的DocumentBuilder在解析过程中就要验证XML文档的正确性。

  回复  引用    

#7楼 2004-09-04 23:54 wayfarer
对!此时相当于builder是生产线,用于组装产品,而工厂则决定了生产线的类型。

在GOF的23种模式中,很多都可以结合的。比如singleTon和工厂模式。

  回复  引用    

#8楼 2004-09-07 12:43 John.J.Dengba
也可以把Builder当作是工厂方法(包括Simple Factory、Factory Method和Abstract Factory三种模式)的产品,之后再由Builder去组装零部件生产出客户端最终需要的产品,这也是一个模式组合的例子,与wayfarer(更远的路?)的想法有些...... :P
  回复  引用    

#9楼 2004-10-19 22:08 sai[未注册用户]
二、 Singleton模式的结构:
应该为
二、 Builder模式的结构:

  回复  引用    

#10楼[楼主] 2004-10-19 22:54 吕震宇      
已经修改过来,谢谢!
  回复  引用  查看    

#11楼 2004-11-15 16:18 blue23[未注册用户]
看了你的C#设计模式(8)Builder Pattern深受启发,
可是想把Factory和Builder混合使用却没有了思路,
还请给个实例
多谢了

  回复  引用    

#12楼 2004-11-16 11:52 吕震宇
@blue23

本文中的第五个评论就是一个java中混合使用Factory和Builder模式的例子。用在了创建XML的DOM模型上面。你可以读一读。

  回复  引用    

#13楼 2005-01-11 16:32 KingofSC
blue23
只要把Builder的第一步创建对象的时候,替换上Factory模式就是组合两种模式了
// "ConcreteBuilder1"
class MotorCycleBuilder : VehicleBuilder
{
// Methods
override public void BuildFrame()
{
vehicle = new Vehicle( "MotorCycle" );
//上面这里可以用Factory模式来代替
//vehicle = VehicleFactory.Create();
vehicle[ "frame" ] = "MotorCycle Frame";
}

不知道我理解对不对

  回复  引用    

#14楼 2005-03-29 13:47 Harry
我的理解:
factory:工厂自己有模具(类),接到order选择不同的模具生产产品
builder:客户下order给工厂的同时也提供生产这些产品的模具,工厂拿到这些模具才能生产产品

  回复  引用    

#15楼 2005-05-09 15:13 pp
还可以用Factory生产不同的Director,这样在相同零部件的情况下也可以由不同的Director拼装出不同的产品

这也是为什么Builder模式里要既有建造者类又要有指导者类了(也是OO的单一职责原则)

  回复  引用    

#16楼 2005-06-24 16:21 cv222
很多人都理解到了问题的本质, 其实factory method就是生产零件的, builder用来组装成品, 当然有可能组装出来的成品相对别的成品而言又是零件...
  回复  引用    

其实,你们都没有理解到本质,之所以有工厂这个概念,是因为开发与维护中,归一化能让两者都得到好处。然后并不是所有的应用总是能够归一化,这个时候,我们必须处理好特殊与一般的关系,尽量将特殊的对象去耦合。Bulider正是基于这样的一个思想而创造的。另外,很多模式我们在实际应用中早就已经涉及,哪怕你还叫不出他的名字,如今有人将它分类,其最重要的意义并不是用来让大家学习,而是为定量分析架构的效率与RUP之间的关系。当然我们拿来学习也是很好的突破口啦,但并不是其真正意义所在。我们大可不必为几个拼凑起来的模式而感到欣喜,甚至认为是创新,这是不对的。正如鲁迅所说,世间原本没有路,走的人多了,并成了路。 设计模式就是这些路吧。
  回复  引用    

#18楼 2005-12-07 14:52 buaaytt      
看了一遍,看代码没问题,但是感觉该模式到底干什么用的还是没有概念。如果楼主能够多一些解释就更好了。个人理解设计模式是应对软件开发中的变化的,如果没有变化,用过程化开发也一样。所以如果楼主能够多讲一些关于该模式如何使用,如何应对变化,以及相对于不使用该模式来应对变化有哪些优点等这方面的内容能够更好地帮助我这样的初学者理解设计模式。
比如我是在看一个实例代码中说到用到了Builder模式就来看这篇文章,但是发现看完了对Builder模式还是不懂。在我看的示例中,有一个Builder类,它创建的又是多个不同类型的Builder,我理解就是对该模式的一种扩展。而且示例中也没有Director,所以我很难把示例和楼主你讲的示例代码看成是同一种模式。
而且我觉得更重要的是我不知道为什么要使用这种模式,其好处在哪里,可以应对哪些变化。这样我就不知道在什么时候可以使用该模式,如何使用,是否需要一些简化或者扩展。
我想楼主的本意是想让更多的人了解设计模式,但是从我的观点来看,讲得比较浅,没有深入分析。
一家之言,希望楼主不要介意!

  回复  引用  查看    

#19楼 2005-12-11 23:20 gshope[未注册用户]
最开始的代码写的有问题,应该:
class Director
{
// Methods
public Product Construct( Builder builder )
{
builder.BuildPartA();
builder.BuildPartB();
return builder.GetResult();
}
}
然后客户端调用时:
......
Product p1 =Director.Construct(new ConcreteBuilder1())
................
其中,new ConcreteBuilder1()这句可以利用反射,把程序集的名称和方法名写到配置文件中,这样客户端和服务器端的Builder 类及其子类的偶合度是最低的,而且今后在变化时也满足开闭原则.

  回复  引用    

编码 - 思考 - 在编码 - 在思考
只有这样。。模式才能慢慢的刻画到你的脑袋中

楼主将得够浅显易懂了。以前比较混淆不明白的地方豁然开朗起来。谢谢~

  回复  引用    

利用反射把程序集的名称和方法名写到配置文件中,这样客户端和服务器端的Builder 类及其子类的偶合度是最低的。如下所示:
string assemblyName = configurationSettings["BuilerAssembly"];
string builderNmae = configurationSettiongs["BuilderClass"];
Assembly assembly = Assembly.Load(assemblyName);
Type t = assembly.GetType("builderName");
Builder builder = Activator.CreateInstance(t);
Product p1 = Director.Construct(builder);

  回复  引用    

反射有性能考虑
  回复  引用    

class MotorCycleBuilder : VehicleBuilder
{
// Methods
override public void BuildFrame()
{
vehicle = new Vehicle( "MotorCycle" );
vehicle[ "frame" ] = "MotorCycle Frame";
}

override public void BuildEngine()
{
vehicle[ "engine" ] = "500 cc";
}

override public void BuildWheels()
{
vehicle[ "wheels" ] = "2";
}

override public void BuildDoors()
{
vehicle[ "doors" ] = "0";
}
}
上面这段代码编译会出错的,
vehicle = new Vehicle( "MotorCycle" );这句话应该提出到这几个类方法之外,现在只在BuildFrame里面声明,其他的方法如何能访问到?

  回复  引用    

不好意思,没有看到在基类已经声明了vehicle。
  回复  引用    

#25楼 2006-08-21 21:29 msjqd[未注册用户]
个人理解:
建造模式和工厂模式基本相同,主要是单对多的关系
不过builder pattern 强调的是组成整体部件的生成顺序。如果业务逻辑没有关系到生成顺序,完全可以不用理睬builder pattern
factory pattern 就是对工厂里面的部件或一类部件进行建造的

  回复  引用    

对于LZ在文章开头提到的“对象性质的建造”,感觉与后面的解释和举例不甚理解,前者提及“有些情况下,一个对象的一些性质必须按照某个顺序赋值才有意义。在某个性质没有赋值之前,另一个性质则无法赋值。这些情况使得性质本身的建造涉及到复杂的逻辑”,而例子中的Director类中却又明明规定了各零件的生产次序,不同的Concrete类只是在各个零件的具体生产方法上有所不同而已,但零件的拼装顺序却已又Director类定义好了,故个人认为Builder Patter并没有很好的解决文章开头提出的有关零件组装顺序的问题。

是否我理解的不对?能否请LZ给具体解释下?

  回复  引用    

是偶理解错误了:)
  回复  引用    

我觉得Builder类不应该定义为抽象类,那样子类就不得不被迫实现Builder所定义的所有抽象方法,这样就限制了Builder模式的精髓,子类可以根据自己的需要来构建对象的表示。
  回复  引用    

#29楼 2007-06-07 10:38 何时若愚      
指导者 好象是 模板方法,而且创建过程的骨架这在指导者身上
  回复  引用  查看    

#30楼 2007-06-07 11:08 何时若愚      
@ggyyppmm
Builder只是对创建的方法进行抽象,对于每一个实现它的子类这是必须去实现的,如果像你所说子类去构建自己的对象而没有统一的接口,在客户程序中怎么去获知你具体子类的方法,这不符合开闭原则,我们要的是面向接口的编程

  回复  引用  查看    

问下,
看你的例子
MotorCycleBuilder,CarBuilder,scooterBuild这三个具体的Builder 类都是实现了一个产品(Vehicle)的具体的4个部分(BuildFrame...)。这不就和Abstract factory一样了吗。选择了MotorCycleBuilder就等于把MotorCycleBuilder里实现的4个部件都选定了,这样不就相当于一个系列的意思吗。也就是说选择了MotorCycle这个系列。

  回复  引用    

吕老师, 你好啊
  回复  引用    

#33楼 2008-02-15 12:52 HeroBeast      
小强控件园应用了你的设计模式文章
http://www.xq168.cn/tagarticle.aspx?TagName=吕震宇

  回复  引用  查看    

--引用--------------------------------------------------
刘余学: 其实,你们都没有理解到本质,之所以有工厂这个概念,是因为开发与维护中,归一化能让两者都得到好处。然后并不是所有的应用总是能够归一化,这个时候,我们必须处理好特殊与一般的关系,尽量将特殊的对象去耦合。Bulider正是基于这样的一个思想而创造的。另外,很多模式我们在实际应用中早就已经涉及,哪怕你还叫不出他的名字,如今有人将它分类,其最重要的意义并不是用来让大家学习,而是为定量分析架构的效率与RUP之间的关系。当然我们拿来学习也是很好的突破口啦,但并不是其真正意义所在。我们大可不必为几个拼凑起来的模式而感到欣喜,甚至认为是创新,这是不对的。正如鲁迅所说,世间原本没有路,走的人多了,并成了路。 设计模式就是这些路吧。
--------------------------------------------------------
这才是精髓!!!!!

  回复  引用    

#35楼 2008-02-25 15:47 jazz[未注册用户]
学习中....收藏
  回复  引用    

这两天一直在看吕老师的文章,感觉您对于设计模式讲得还是很清楚的,谢谢!
  回复  引用    

#37楼 2008-04-28 16:22 wayich      
学习中。
  回复  引用  查看    

#38楼 2008-11-03 11:08 snow man      
牛X啊 呵呵

  回复  引用  查看