代码改变世界

C#面向对象设计模式纵横谈 笔记4 Builder 生成器(创建型模式)

2011-08-14 21:47  lujiao_cs  阅读(262)  评论(0编辑  收藏  举报

Builder模式的缘起

1)假设创建游戏中的一个房屋House设施,该房屋的构建由几个部分组成,且各个部分要富于变化。 

2)如果使用最直观的设计方法,每一个房屋部分的变化,都将导致房屋构建的重新修正

动机(Motivation

在软件系统中,有时候面临着一个复杂对象的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法相对稳定

如何应对这种变化?如何提供一种封装机制来隔离出复杂对象的各个部分的变化,从而保持系统中的稳定构建算法不随着需求改变而改变?

在新的需求动态变化的过程中,分析处系统比较脆弱的部分隔离出来,而不要与稳定的部分纠缠在一起,导致不必要的修改。

意图(Intent

将一个复杂对象的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。        —— 《设计模式》GoF

不同的表示就是变化,例如:对于一个房屋,变化的房顶,变化的窗户。同样的构建过程房屋的构建过程不变

结构(Structure

GameManager是一个使用者的角色,是一个客户程序,它根据传入的Builder类对象依据稳定的算法来构造房屋。

Builder: 是一个生成器。

RomanHouseBuilder:是某一具体的Builder

游戏框架中的Builder应用 Codes in .NET

1Builder.cs 这是系统的轴线部分

   /// <summary>
/// 抽象房屋类
/// </summary>
public abstract class House
{ }

public abstract class Door
{ }
public abstract class Wall
{ }
public abstract class Windows
{ }
public abstract class Floor
{ }
public abstract class HouseCeiling
{ }

/// <summary>
/// 房屋构造者
/// </summary>
public abstract class Builder
{
# region 屋子的各个部分:不关心具体的表示,如门是怎样的,墙是怎样的。但是我们可以将高层的抽象部分,即系统的轴线部分抽象而定义出来。

/// <summary>
/// 创建门
/// </summary>
public abstract void BuildDoor();
/// <summary>
/// 创建墙
/// </summary>
public abstract void BuildWall();
/// <summary>
/// 创建窗户
/// </summary>
public abstract void BuildWindows();
/// <summary>
/// 创建地板
/// </summary>
public abstract void BuildFloor();
/// <summary>
/// 创建天花板
/// </summary>
public abstract void BuildHouseCeiling();

#endregion

/// <summary>
/// 一个完整的屋子
/// </summary>
/// <returns></returns>
public abstract House GetHouse();
}

2)客户程序GameManager.cs 此需求是相对稳定的其与抽象类Builder绑定的比较紧密

 

   public class GameManager
{
/// <summary>
/// 创建房子的过程:其通过传入的一个 Builder 来构建 House
/// </summary>
/// <param name="builder"></param>
/// <returns></returns>
public static House CreateHouse(Builder builder)
{
builder.BuildDoor();
builder.BuildDoor();

builder.BuildWindows();
builder.BuildWindows();

builder.BuildWall();
builder.BuildWall();
builder.BuildWall();
builder.BuildWall();

builder.BuildFloor();
builder.BuildHouseCeiling();

return builder.GetHouse();
}
}

3)罗马风格的房子

    public class RomanHouse:House
{
//...... }

public class RomanDoor : Door
{
// ...... }

public class RomanWall : Wall
{
//...... }

public class RomanWindows : Windows
{
//...... }

public class RomanFloor : Floor
{
//...... }

public class RomanHouseCeiling : HouseCeiling
{
//...... }

/// <summary>
/// 变化点在这里,可能会有新的风格的房子,如:MoernHouseBuilder
/// </summary>
public class RomanHouseBuilder:Builder
{
public override void BuildDoor()
{
//......}

public override void BuildWall()
{
// ......}

public override void BuildWindows()
{
//......}

public override void BuildFloor()
{
//...... }

public override void BuildHouseCeiling()
{
//......}

public override House GetHouse()
{
//......
}
}

4)主程序

//添加相应风格的房屋(如MoernHouseBuilder)并且由配置文件配置具体使用的Builder,符合开放封闭原则(利用扩展的方式来修改系统,即对扩展开放,对修改关闭。)
//房屋的构建过程是一个高层抽象,房屋的房顶、窗户等是实现细节,这些实现细节应该依赖于高层抽象而不是反过来。
//高层抽象是比较稳定的,而细节是相对比较脆弱的。
//设计模式很多都柔和了经典的面向对象的原则.
class Program
{
static void Main(string[] args)
{
String assemblyName
= ConfigurationSettings.AppSettings["BuildAssembly"];
String buildName
= ConfigurationSettings.AppSettings["BuildClasss"];

Assembly assembly
= Assembly.Load(assemblyName);

Type t
= assembly.GetType(buildName);

Builder builder
= (Builder)Activator.CreateInstance(t);
House house
= GameManager.CreateHouse(builder);
   }
}

Builder 模式的几个要点

1)Builder 模式主要用于分步骤构建一个复杂的对象。在这其中分步骤是一个稳定的算法,而复杂对象的各个部分则经常变化。

2)变化点在哪里,封装哪里—— Builder模式主要在于应对复杂对象各个部分的频繁需求变动。其缺点在于难以应对分步骤构建算法的需求变动即上例中的GameManager类内容

3)Abstract Factory模式解决系列对象丛林、鹿等是相互耦合的关系的需求变化,Builder模式解决对象部分如:窗、门都是同属一个大对象的子对象的需求变化Builder模式通常和Composite模式组合使用。抽象工厂模式和Builder模式有很多相似之

.NET框架中的Builder应用 Codes in .NET

Page 就相当于一个抽象的BuilderOnInitOnLoadOnPreRender 就相当于 BuilderPart,他们都是虚方法,我们可以重写。

CodeBehind 类继承自Page类,aspx 页面被解析器解析为C#的类,这个类是继承自CodeBehind 类。这个类会有一个构造的过程(页面的构造过程是稳定不变的),这些过程放到不同的BuildPart里面执行(而不同的构造过程是根据实际情况变化的)。

推荐参考书

1)《设计模式:可复用面向对象软件的基础》GoF

2)《面向对象分析与设计》Grady Booch

3)《敏捷软件开发:原则、模式与实践》Robert C. Martin

4)《重构:改善既有代码的设计》Martin Fowler

5)Refactoring to PatternsJoshua Kerievsky