示例工程【免费下载链接】Unity3DTraining【Unity杂货铺】unity大杂烩~项目地址https://gitcode.com/gh_mirrors/un/Unity3DTraining点击查看免费下载建造者模式Builder Pattern又称生成器模式是 GoF 二十三种设计模式中典型的创建型模式其核心思想是将复杂对象的构建过程与产品本身解耦让构造算法与组成部件相互独立由统一的指挥者Director按固定步骤驱动建造者Builder从而在保证流程稳定的前提下产出不同表象的产品。本文以 Unity3DTraining 仓库中 DesignPatterns/BuilderPattern 的讲解文档为骨架结合配套的 C# 控制台工程源码完整剖析经典四角色结构、老师/学生化学实验的教学案例、与工厂模式的区别、适用场景与无 Director 变体读完即可在自己的项目中落地按步骤、可替换、不遗漏的对象构建方案。一、模式概述为什么需要按部就班地造对象在真实项目中经常会遇到需要构建比较复杂的对象并对其多个属性进行赋值的复杂操作。此时程序员的一时疏忽可能导致某个属性未被赋值进而引起对象的失效。建造者模式正是针对这类问题而设计创建一个 Director指挥者来按部就班地指挥一个对象的创建可以有效避免意外发生。使用建造者模式后用户只需要指定创建的类型就可以得到相应的对象而具体的建造过程和细节就被 Director 和 Builder 隐藏了。这正是依赖倒转原则的体现——抽象不应该依赖于细节细节应该依赖于抽象。文档中给出的角色类比非常直观老师Teacher扮演Director指挥者角色学生Student扮演Builder建造者角色Teacher 隔离了客户端与具体步骤的依赖。二、模式四角色职责边界与协作关系建造者模式由四个核心角色组成配套源码分布在 BuilderPattern 目录下一一对应角色职责仓库对应类型文件Product产品被构建的复杂对象由多个部件组成Product.csBuilder抽象建造者声明构建各个部件的抽象接口Builder.csConcreteBuilder具体建造者实现各部件构建逻辑提供获取产品的方法ConcreteBuliderA / ConcreteBuilderBBuilder.csDirector指挥者定义构建算法的步骤顺序与具体部件解耦DirectorBuilder.cs四个角色协作时客户端只面向 Director 和抽象 Builder 编程产品内部的组装过程被完整隐藏。下面结合源码逐层拆解。1. 产品类 ProductProduct.cs 用Liststring收集组装出来的部件并提供Add与Show两个方法class Product { Liststring parts new Liststring(); public void Add(string part) { parts.Add(part); } public void Show() { Console.WriteLine(Create Product); for (int i 0; i parts.Count; i) { Console.WriteLine(parts[i]); } } }2. 抽象建造者 Builder 与两个具体建造者Builder.cs 中抽象类Builder声明了两个部件构建步骤BuilderPartA()、BuilderPartB()以及获取结果的GetResult()abstract class Builder { public abstract void BuilderPartA(); public abstract void BuilderPartB(); public abstract Product GetResult(); }两个具体建造者分别向产品中填充不同的部件内容ConcreteBuliderA组装 Part A / Part BConcreteBuilderB组装 Part W / Part Z。由于都继承自同一个抽象基类相同的构建步骤可以被替换出完全不同的产品表象——这正是多态性在建造者模式中的典型应用。class ConcreteBuilderB : Builder { private Product product new Product(); public override void BuilderPartA() { product.Add(Part W); } public override void BuilderPartB() { product.Add(Part Z); } public override Product GetResult() { return product; } }3. 指挥者 Director 固定构建算法同一个 Builder.cs 中Director.Construct()只依赖抽象的Builder接口按固定顺序调用步骤class Director { public void Construct(Builder builder) { builder.BuilderPartA(); builder.BuilderPartB(); } }指挥者本身不关心具体建造者往部件里放了什么内容只保证先 Part A、再 Part B的算法顺序不被破坏这就是文档中所说的保持对象创造过程的稳定性。三、仓库配套演示两种形态的完整跑通1. 经典形态Director 指挥两个 ConcreteBuilderProgram.cs 是控制台程序入口工程为 .NET Framework 4.5.2见 BuilderPattern.csproj 与 App.config客户端只做三件事创建 Director、准备不同 Builder、交由 Director 构建并取结果Director director new Director(); Builder builderA new ConcreteBuliderA(); Builder builderB new ConcreteBuilderB(); director.Construct(builderA); Product productA builderA.GetResult(); productA.Show(); director.Construct(builderB); Product productB builderB.GetResult(); productB.Show();运行后productA.Show()依次输出 Part A / Part BproductB.Show()依次输出 Part W / Part Z——同一套 Director 算法产出两种不同内部表示的产品。2. 教学形态老师指挥学生完成化学实验这是文档中老师为 Director 角色、学生为 Builder 角色的具体落点。抽象学生基类 Student.cs 把实验流程固定为四个步骤public abstract class Student { public abstract void PrePareEx(); // 实验前的准备工作 public abstract void PourReagent(); // 加入氢氧化钡 public abstract void PourCarbon(); // 加入二氧化碳 public abstract void ShowResult(); // 展示实验结果 }由于抽象类定义了系列抽象方法子类如果不实现就会编译报错从语言层面杜绝了漏做某个步骤导致实验失败的可能——这正是建造者模式防止属性/步骤遗漏的机制。两个具体学生继承该基类并各自实现步骤StudentA.cs通入少量二氧化碳结果出现了沉淀StudentB.cs通入大量二氧化碳结果出现沉淀后又消失了。指挥者老师 Teacher.cs 持有抽象Student通过构造器注入后按固定顺序指导实验class Teacher { private Student student; public Teacher(Student student) { this.student student; } //老师指导学生实验 public void DirectExperiment() { student.PrePareEx(); student.PourReagent(); student.PourCarbon(); student.ShowResult(); } }客户端同样只需替换具体学生即可切换实验结果Program.csStudent studentA new StudentA(); Teacher teacher new Teacher(studentA); teacher.DirectExperiment(); // 输出出现了沉淀 teacher new Teacher(new StudentB()); teacher.DirectExperiment(); // 输出出现沉淀后又消失了实验流程完全一致仅仅替换具体建造者就得到了不同的实验结果——也就是改变产品的内部表示试剂添加量只需要再定义一个具体建造者的直接证明。四、建造者模式 VS 工厂模式同门不同道建造者模式与工厂模式都属于创建型模式目的都是得到一个对象但侧重点截然不同详见 README.md 的对比章节对比维度工厂模式建造者模式侧重点将对象的实例化延迟到子类保持对象创造过程的稳定性产品表象创建相同表象的对象在固定步骤下得到多种表象的实例与客户端的关系都隔离了创建过程都隔离了创建过程选择依据面包烤制柜台只需向工厂拿同一类面包化学实验步骤相同但结果不同文档用两个生活化例子做了精辟类比面包的烤制只是创建了很多同种类型的面包柜台只需向工厂拿面包即可而化学实验则侧重于得到不同表象、也就是实验结果不同的情况。因此当需要固定流程但希望产出多样产品时应选择建造者模式。此外建造者模式是多态性使用的绝佳载体Teacher/Director面对的是抽象的Student/Builder接口运行时传入哪个具体实现就产出哪种产品扩展新学生/新建造者完全不需要改动指挥者代码。五、适用场景与无 Director 变体1. 适用场景判定建造者模式可以说是对流程的抽象当出现以下两种情况时适合使用README.md 小结创建复杂对象的算法应该独立于该对象的组成部分以及它们的组装方式把构造算法收敛到 Director 中部件与组装互不影响构造过程必须允许被构造的对象有不同的表示步骤固定、输出可变强调对象的差异性。同时它还有两个实用的副作用用途把构造对象的实例逻辑转移到类外面去在这个类的外部定义其构造逻辑当某个类包含大量方法、规模过大时可用建造者模式拆分构造职责当只能按部就班地获取构造方法所需要的参数时参数依赖前置步骤建造者天然契合这种顺序化构造场景。2. 无 Director 的建造者模式变体在构造步骤算法比较少的情况下可以采用无 Director 的建造者模式由客户端直接调用具体建造者的各步骤方法。这样做虽然增加了客户端对具体构建过程的依赖性但是可以降低程序复杂性。文档明确提示在实际项目应用中应该灵活运用而不是教条式地套用模板——例如当流程只有两三个固定步骤且产品变体很少时直接让客户端驱动 Builder 反而更清爽。六、模式优点与开放-封闭原则建造者模式的核心优点原文四点在源码中均有印证客户端与产品细节解耦客户端不必知道产品内部组成的具体细节产品本身与创建过程解耦相同的创建过程可以创建出不同的产品对象——对应Director.Construct()用同一算法产出 ProductA/ProductB具体建造者相互独立、易于替换与扩展每个具体建造者相对独立替换或新增具体建造者即可得到不同产品——对应StudentA/StudentB的即插即用创建过程精细可控将复杂产品的创建步骤分解在不同方法中过程清晰、便于程序控制——对应PrePareEx → PourReagent → PourCarbon → ShowResult的显式步骤拆分符合开放-封闭原则增加新的具体建造者不用修改原类库代码指挥者类针对抽象建造者类编程系统扩展方便——新增一个StudentC只需继承Student实现四个方法Teacher与客户端零改动。七、小结建造者模式的价值在于它把对象的构造算法从对象的部件与组装方式中彻底剥离用指挥者锁定流程、用多态换取差异。在 Unity3DTraining 仓库中BuilderPattern 工程通过 Product/Director/Builder 的经典形态与 Teacher/Student 的教学形态完整演示了从角色划分、源码实现到客户端调用的全过程。参考代码可直接阅读 Program.cs 入口结合 README.md 的对比与小结即可在复杂对象构建、多步骤流程组装等场景中灵活取舍带 Director与无 Director两种形态做到知其然更知其所以然。输出文章Unity3DTraining 建造者模式实战从化学实验教学到复杂对象的分步构建建造者模式Builder Pattern又称生成器模式是 GoF 二十三种设计模式中典型的创建型模式其核心思想是将复杂对象的构建过程与产品本身解耦让构造算法与组成部件相互独立由统一的指挥者Director按固定步骤驱动建造者Builder从而在保证流程稳定的前提下产出不同表象的产品。本文以 Unity3DTraining 仓库中 DesignPatterns/BuilderPattern 的讲解文档为骨架结合配套的 C# 控制台工程源码完整剖析经典四角色结构、老师/学生化学实验的教学案例、与工厂模式的区别、适用场景与无 Director 变体读完即可在自己的项目中落地按步骤、可替换、不遗漏的对象构建方案。一、模式概述为什么需要按部就班地造对象在真实项目中经常会遇到需要构建比较复杂的对象并对其多个属性进行赋值的复杂操作。此时程序员的一时疏忽可能导致某个属性未被赋值进而引起对象的失效。建造者模式正是针对这类问题而设计创建一个 Director指挥者来按部就班地指挥一个对象的创建可以有效避免意外发生。使用建造者模式后用户只需要指定创建的类型就可以得到相应的对象而具体的建造过程和细节就被 Director 和 Builder 隐藏了。这正是依赖倒转原则的体现——抽象不应该依赖于细节细节应该依赖于抽象。文档中给出的角色类比非常直观老师Teacher扮演Director指挥者角色学生Student扮演Builder建造者角色Teacher 隔离了客户端与具体步骤的依赖。二、模式四角色职责边界与协作关系建造者模式由四个核心角色组成配套源码分布在 BuilderPattern 目录下一一对应角色职责仓库对应类型文件Product产品被构建的复杂对象由多个部件组成Product.csBuilder抽象建造者声明构建各个部件的抽象接口Builder.csConcreteBuilder具体建造者实现各部件构建逻辑提供获取产品的方法ConcreteBuliderA / ConcreteBuilderBBuilder.csDirector指挥者定义构建算法的步骤顺序与具体部件解耦DirectorBuilder.cs四个角色协作时客户端只面向 Director 和抽象 Builder 编程产品内部的组装过程被完整隐藏。下面结合源码逐层拆解。1. 产品类 ProductProduct.cs 用Liststring收集组装出来的部件并提供Add与Show两个方法class Product { Liststring parts new Liststring(); public void Add(string part) { parts.Add(part); } public void Show() { Console.WriteLine(Create Product); for (int i 0; i parts.Count; i) { Console.WriteLine(parts[i]); } } }2. 抽象建造者 Builder 与两个具体建造者Builder.cs 中抽象类Builder声明了两个部件构建步骤BuilderPartA()、BuilderPartB()以及获取结果的GetResult()abstract class Builder { public abstract void BuilderPartA(); public abstract void BuilderPartB(); public abstract Product GetResult(); }两个具体建造者分别向产品中填充不同的部件内容ConcreteBuliderA组装 Part A / Part BConcreteBuilderB组装 Part W / Part Z。由于都继承自同一个抽象基类相同的构建步骤可以被替换出完全不同的产品表象——这正是多态性在建造者模式中的典型应用。class ConcreteBuilderB : Builder { private Product product new Product(); public override void BuilderPartA() { product.Add(Part W); } public override void BuilderPartB() { product.Add(Part Z); } public override Product GetResult() { return product; } }3. 指挥者 Director 固定构建算法同一个 Builder.cs 中Director.Construct()只依赖抽象的Builder接口按固定顺序调用步骤class Director { public void Construct(Builder builder) { builder.BuilderPartA(); builder.BuilderPartB(); } }指挥者本身不关心具体建造者往部件里放了什么内容只保证先 Part A、再 Part B的算法顺序不被破坏这就是文档中所说的保持对象创造过程的稳定性。三、仓库配套演示两种形态的完整跑通1. 经典形态Director 指挥两个 ConcreteBuilderProgram.cs 是控制台程序入口工程为 .NET Framework 4.5.2见 BuilderPattern.csproj 与 App.config客户端只做三件事创建 Director、准备不同 Builder、交由 Director 构建并取结果Director director new Director(); Builder builderA new ConcreteBuliderA(); Builder builderB new ConcreteBuilderB(); director.Construct(builderA); Product productA builderA.GetResult(); productA.Show(); director.Construct(builderB); Product productB builderB.GetResult(); productB.Show();运行后productA.Show()依次输出 Part A / Part BproductB.Show()依次输出 Part W / Part Z——同一套 Director 算法产出两种不同内部表示的产品。2. 教学形态老师指挥学生完成化学实验这是文档中老师为 Director 角色、学生为 Builder 角色的具体落点。抽象学生基类 Student.cs 把实验流程固定为四个步骤public abstract class Student { public abstract void PrePareEx(); // 实验前的准备工作 public abstract void PourReagent(); // 加入氢氧化钡 public abstract void PourCarbon(); // 加入二氧化碳 public abstract void ShowResult(); // 展示实验结果 }由于抽象类定义了系列抽象方法子类如果不实现就会编译报错从语言层面杜绝了漏做某个步骤导致实验失败的可能——这正是建造者模式防止属性/步骤遗漏的机制。两个具体学生继承该基类并各自实现步骤StudentA.cs通入少量二氧化碳结果出现了沉淀StudentB.cs通入大量二氧化碳结果出现沉淀后又消失了。指挥者老师 Teacher.cs 持有抽象Student通过构造器注入后按固定顺序指导实验class Teacher { private Student student; public Teacher(Student student) { this.student student; } //老师指导学生实验 public void DirectExperiment() { student.PrePareEx(); student.PourReagent(); student.PourCarbon(); student.ShowResult(); } }客户端同样只需替换具体学生即可切换实验结果Program.csStudent studentA new StudentA(); Teacher teacher new Teacher(studentA); teacher.DirectExperiment(); // 输出出现了沉淀 teacher new Teacher(new StudentB()); teacher.DirectExperiment(); // 输出出现沉淀后又消失了实验流程完全一致仅仅替换具体建造者就得到了不同的实验结果——也就是改变产品的内部表示试剂添加量只需要再定义一个具体建造者的直接证明。四、建造者模式 VS 工厂模式同门不同道建造者模式与工厂模式都属于创建型模式目的都是得到一个对象但侧重点截然不同详见 README.md 的对比章节对比维度工厂模式建造者模式侧重点将对象的实例化延迟到子类保持对象创造过程的稳定性产品表象创建相同表象的对象在固定步骤下得到多种表象的实例与客户端的关系都隔离了创建过程都隔离了创建过程选择依据面包烤制柜台只需向工厂拿同一类面包化学实验步骤相同但结果不同文档用两个生活化例子做了精辟类比面包的烤制只是创建了很多同种类型的面包柜台只需向工厂拿面包即可而化学实验则侧重于得到不同表象、也就是实验结果不同的情况。因此当需要固定流程但希望产出多样产品时应选择建造者模式。此外建造者模式是多态性使用的绝佳载体Teacher/Director面对的是抽象的Student/Builder接口运行时传入哪个具体实现就产出哪种产品扩展新学生/新建造者完全不需要改动指挥者代码。五、适用场景与无 Director 变体1. 适用场景判定建造者模式可以说是对流程的抽象当出现以下两种情况时适合使用README.md 小结创建复杂对象的算法应该独立于该对象的组成部分以及它们的组装方式把构造算法收敛到 Director 中部件与组装互不影响构造过程必须允许被构造的对象有不同的表示步骤固定、输出可变强调对象的差异性。同时它还有两个实用的副作用用途把构造对象的实例逻辑转移到类外面去在这个类的外部定义其构造逻辑当某个类包含大量方法、规模过大时可用建造者模式拆分构造职责当只能按部就班地获取构造方法所需要的参数时参数依赖前置步骤建造者天然契合这种顺序化构造场景。2. 无 Director 的建造者模式变体在构造步骤算法比较少的情况下可以采用无 Director 的建造者模式由客户端直接调用具体建造者的各步骤方法。这样做虽然增加了客户端对具体构建过程的依赖性但是可以降低程序复杂性。文档明确提示在实际项目应用中应该灵活运用而不是教条式地套用模板——例如当流程只有两三个固定步骤且产品变体很少时直接让客户端驱动 Builder 反而更清爽。六、模式优点与开放-封闭原则建造者模式的核心优点原文四点在源码中均有印证客户端与产品细节解耦客户端不必知道产品内部组成的具体细节产品本身与创建过程解耦相同的创建过程可以创建出不同的产品对象——对应Director.Construct()用同一算法产出 ProductA/ProductB具体建造者相互独立、易于替换与扩展每个具体建造者相对独立替换或新增具体建造者即可得到不同产品——对应StudentA/StudentB的即插即用创建过程精细可控将复杂产品的创建步骤分解在不同方法中过程清晰、便于程序控制——对应PrePareEx → PourReagent → PourCarbon → ShowResult的显式步骤拆分符合开放-封闭原则增加新的具体建造者不用修改原类库代码指挥者类针对抽象建造者类编程系统扩展方便——新增一个StudentC只需继承Student实现四个方法Teacher与客户端零改动。七、小结建造者模式的价值在于它把对象的构造算法从对象的部件与组装方式中彻底剥离用指挥者锁定流程、用多态换取差异。在 Unity3DTraining 仓库中BuilderPattern 工程通过 Product/Director/Builder 的经典形态与 Teacher/Student 的教学形态完整演示了从角色划分、源码实现到客户端调用的全过程。参考代码可直接阅读 Program.cs 入口结合 README.md 的对比与小结即可在复杂对象构建、多步骤流程组装等场景中灵活取舍带 Director与无 Director两种形态做到知其然更知其所以然。赞分享示例工程【免费下载链接】Unity3DTraining【Unity杂货铺】unity大杂烩~项目地址https://gitcode.com/gh_mirrors/un/Unity3DTraining点击查看免费下载相关推荐Swift建造者模式一步步构建复杂的DeathStar对象 ️Swift建造者模式是一种强大的设计模式专门用于创建复杂对象。通过分离对象的构造过程与其表示建造者模式让你能够使用相同的构建过程创建不同的对象表现。本文将详示例工程提升开发效率10倍repository-harness CLI命令实用指南提升开发效率10倍repository harness CLI命令实用指南 repository harness是一款能将任何代码仓库转换为适用于ClaudeUrsinaPython游戏开发的极简主义革命UrsinaPython游戏开发的极简主义革命 在Python生态中游戏开发一直被视为相对薄弱的领域——直到Ursina的出现。这款基于Panda3D的3D上一篇WebPShop为Photoshop用户提供专业级WebP格式支持插件下一篇F´ 框架中的 Drv::Udp 组件基于 UDP 的字节流驱动实现与实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考