设计模式03: Builder 生成器模式(创建型模式)

Builder生成器模式(创建型模式)

Builder模式缘起
假设创建游戏中的一个房屋House设施,该房屋的构建由几个部分组成,且各个部分富于变化。
如果使用最直观的设计方法,每个房屋部分的变化,都将导致房屋构建的重新修正...

动机(Motivation)
在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将他们组合在一起的算法却非常稳定。
如何应对这种变化?如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化,从而保证系统中的“稳定构建算法”不随需求改变而改变?

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

游戏框架中Builder应用,示例代码只是个框架,没有具体实现

public abstract class House
{

}
public abstract class Door
{

}
public abstract class Wall
{

}
public abstract class Windows
{

}
public abstract class Floor
{

}
public abstract class HouseCeiling
{

}
public abstract class RomanHouse:House
{

}
public class RomanDoor:Door
{

}
public class RomanWall:Wall
{

}
public class RomanWindows:Windows
{

}
public class RomanFloor:Floor
{

}
public class RomanHouseCeiling:HouseCeiling
{

}
public abstract class Builder
{
    public abstract void BuildDoor();
    public abstract void BuildWall();
    public abstract void BuildWindows();
    public abstract void BuildFloor();
    public abstract void BuildHouseCeiling();

    public abstract House GetHouse();
}
public abstract class RomanBuilder: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()
    {

    }
}
public class GameManager
{
    public static House CreateHouse(Builder builder)//构建过程在系统中是相对稳定的地方
    {
        builder.BuiildDoor();
        builder.BuiildDoor();

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

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

        builder.BuildFloor();

        builder.BuildHouseCeiling();

        return bilder.GetHouse();
    }
}
class App
{
    public static void Main()
    {
        //House house = GameManager.CreateHouse(RomanBuilder builder);

        //也可通过读取配置文件,反射来构建House
        string assemblyName=ConfigurationSettings["BuilderAssembly"];//程序集名称
        string builderName = ConfigurationSettings["BuilderClass"];//类名称

        Assembly assembly=Assembly.Load(assemblyName);
        Type t=assembly.GetType(builderName);

        Builder builder = Activator.CreateInstance(t);

        House house = GameManager.CreateHouse(builder);
    }
}

开放关闭原则:对扩展开放,对修改关闭

Builder模式的几个要点:
Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法,而复杂对象的各个部分则经常变化。
变化点在哪里,封装在哪里——Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
Abstract Factory模式解决“系列对象”的需求变化,Builder模式解决“对象部分”的需求变化。
Builder模式通常和Composite模式组合使用。

时间: 2024-08-06 01:22:32

设计模式03: Builder 生成器模式(创建型模式)的相关文章

设计模式(二): BUILDER生成器模式 -- 创建型模式

1.定义 将一个复杂对象的构造与它的表示分离,使同样的构建过程可以创建不同的表示,这样的设计模式被称为建造者模式. 2.适用场景 1. 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时. 2. 当构造过程必须允许被构造的对象有不同表示时. 3.评价 1. 它使你可以改变一个产品的内部表示. Builder对象提供给导向器一个构造产品的抽象接口.该接口使得生成器可以隐藏这个产品的表示和内部结构.它同时也隐藏了该产品是如何装配的.因为产品是通过抽象接口构造的,你在改变该产品的内部表

生成器模式(Builder)-- 对象创建型模式

1. 动机 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.一个RTF(Rich Text Format)文档交换格式的阅读器应能将RTF转换为多种正文格式.该阅读器可以将RTF文档转换成普通ASCII文本或转换成一个能以交互方式编辑的正文窗口组件.但问题在于可能转换的数目是无限的.因此要能够很容易实现新的转换的增加,同时却不改变RTF阅读器.其实也就是,前面的数据接卸(源头处理)归解析,后续的显示处理,由显示处理的部分来完成.在数据解析和显示处理之间架设一个标准的桥梁

设计模式(五) : 创建型模式--建造者模式

建造者模式的意图是将产品的内部表象和产品的生产过程分割开来. 类图: 示意性代码: package com.javadesignpattern.builder; public interface Builder { public void buildPart1(); public void buildPart2(); public Product retrieveProduct(); } ? 1 2 3 4 5 6 7 package com.javadesignpattern.builder;

php设计模式(一):简介及创建型模式

我们分三篇文章来总结一下设计模式在PHP中的应用,这是第一篇创建型模式. 一.设计模式简介 首先我们来认识一下什么是设计模式: 设计模式是一套被反复使用.容易被他人理解的.可靠的代码设计经验的总结. 设计模式不是Java的专利,我们用面向对象的方法在PHP里也能很好的使用23种设计模式. 那么我们常说的架构.框架和设计模式有什么关系呢? 架构是一套体系结构,是项目的整体解决方案:框架是可供复用的半成品软件,是具体程序代码.架构一般会涉及到采用什么样的框架来加速和优化某部分问题的解决,而好的框架代

23种设计模式介绍(一)---- 创建型模式

由于设计模式篇幅比较大,如果在一篇文章讲完所有的设计模式的话不利于阅读.于是我把它分为三篇文章 23种设计模式介绍(一)---- 创建型模式 23种设计模式介绍(二)---- 结构型模式 23种设计模式介绍(三)---- 行为型模式 由于设计模式都是比较抽象的概念,所以大家一定要确保看懂类图,而后再自己写代码加强记忆. 简介 设计模式分为三大类: 创建型模式,共五种:工厂方法模式.抽象工厂模式.单例模式.建造者模式.原型模式. 结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接

设计模式(三) : 创建型模式--工厂方法模式

工厂方法模式区别与简单工厂模式主要在于,factory中对对象的实例化延迟到了子类的factory中, 这也是优于简单工厂的地方.下面看这个模式的类图(截自<java与模式>): 示意性代码: ? 1 2 3 4 5 6 7 package com.javadesignpattern.factorymethod; public interface Creator {          public Product fatcory(); } package com.javadesignpatte

设计模式(六):Singleton 单件模式 -- 创建型模式

1.定义 当需要控制一个类的实例数量且调用者可以从一个公共的访问点访问时. 2.适用场景 1. 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时. 2. 当这个唯一实例应该是通过子类化可扩展的,并且客户应该无需更改代码就能使用一个扩展的实例时. 3.评价 优点: 1. 对唯一实例的受控访问, 因为Singleton类封装它的唯一实例,所以它可以严格的控制客户怎样以及何时访问它. 2. 缩小名空间,Singleton模式是对全局变量的一种改进.它避免了那些存储唯一实例的全局变量污染名空

设计模式(五):PROTOTYPE原型模式 -- 创建型模式

1.定义 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象. 2.适用场景 原型模式的主要思想是基于现有的对象克隆一个新的对象出来,一般是有对象的内部提供克隆的方法,通过该方法返回一个对象的副本,这种创建对象的方式,相比我们之前说的几类创建型模式还是有区别的,之前的讲述的工厂模式与抽象工厂都是通过工厂封装具体的new操作的过程,返回一个新的对象,有的时候我们通过这样的创建工厂创建对象不值得,特别是以下的几个场景的时候,可能使用原型模式更简单也效率更高. • 1)当一个系统应该独立于

设计模式(四) : 创建型模式--单例模式

单例模式的话,类图上来看是最简单的设计模式,就是一个类只能有一个自己的实例. 单例模式通常来说我们就有Lazy loading的和不是Lazy loading的.<java与模式>里面的关于这两种的类图,: 可以看到一个是现开始就实例话的,这样的话不符合我们的lazy loading,还有一种是在getinstance方法里头去new的,这样的话会有线程安全的问题,我们提供了双重检查锁. 下面看示意代碼︰ 1. 静态初始化: package com.javadesignpattern.Sing

设计模式(三): FACTORY工厂模式 -- 创建型模式

1.定义 定义一个用于创建对象的接口,让子类决定实例化哪一个类,Factory Method使一个类的实例化延迟到了子类. 2.适用场景 1.第一种情况是对于某个产品,调用者清楚地知道应该使用哪个具体工厂服务,实例化该具体工厂,生产出具体的产品来.Java Collection中的iterator() 方法即属于这种情况. 2.第二种情况,只是需要一种产品,而不想知道也不需要知道究竟是哪个工厂为生产的,即最终选用哪个具体工厂的决定权在生产者一方,它们根据当前系统的情况来实例化一个具体的工厂返回给