前言：笔者在最开始写程序的时候经常会遇到一种情况，例如更改一个字段、或者添加一种小功能，就要把原来写过的东西几乎废弃掉，或者更改大量以前写过的代码。又或者自己写的东西时间久了再去回顾，完全找不到到时为什么这么写的头绪，如果遇到了Bug更是无法快速定位在哪里小范围出现的问题。如果你也经常遇到这种问题，就说明你现阶段非常需要学习下设计模式了。
在网上经常说的设计模式有23种，也有一些更多的设计模式，无非也是从这些设计模式中变种而来。如果让笔者来形容什么是设计模式，我认为设计模式是：一种思想，一种模式，一种套路，一种解决问题的高效策略。
有说的不正确或者不准确的地方欢迎留言指正
有什么有趣的写作技巧或者想法欢迎大家给我留言，大家的帮助是我写下去最有效的动力
一个产品从原材料到成品要经过很多工序，多种工序经过流水线式的生产产出源源不断的产品。例如盖房子：首先你要准备水泥，钢筋，砖块，然后盖一层、二层、三层直到最高层，通电，通水等等多道“工序”才能完成成品。其中每一道工序都是对产品的全新创建、但是我们只关心最后的终极产品---【房子】。对于这种很复杂的创造过程，其实在设计模式中也有相应的应用，那就是建造者模式。
建造者模式（Builder）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
示例代码
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using Custom.Log;
# region BaseClass
/// <summary>
/// 水泥
/// </summary>
public class Cement { }
/// <summary>
/// 砖块
/// </summary>
public class Brick { }
/// <summary>
/// 钢筋
/// </summary>
public class Rebar { }
/// <summary>
/// 楼层
/// </summary>
public class Floor { }
/// <summary>
/// 水
/// </summary>
public class Water { }
/// <summary>
/// 电
/// </summary>
public class Electricity { }
/// <summary>
/// 房屋
/// </summary>
public class House { }
#endregion
public abstract class AbstractBuilder
{
public abstract void Builde_Cement();
public abstract void Builde_Brick();
public abstract void Builde_Rebar();
public abstract void Builde_Floor();
public abstract void Builde_Water();
public abstract void Builde_Electricity();
public abstract House Builde_House();
}
public class BuilderHouse : AbstractBuilder
{
public override void Builde_Brick()
{
this.Log("建造砖块");
}
public override void Builde_Cement()
{
this.Log("建造水泥");
}
public override void Builde_Electricity()
{
this.Log("建造电力");
}
public override void Builde_Floor()
{
this.Log("建造楼层");
}
public override void Builde_Rebar()
{
this.Log("建造钢筋");
}
public override void Builde_Water()
{
this.Log("建造水");
}
public override House Builde_House()
{
this.Log("房屋建造完成");
return new House();
}
}
public class Director
{
private AbstractBuilder abstractBuilder = null;
public Director(AbstractBuilder tempAbstractBuilder)
{
abstractBuilder = tempAbstractBuilder;
}
public House GetResult()
{
abstractBuilder.Builde_Brick();//建造砖块
abstractBuilder.Builde_Cement();//建造水泥
abstractBuilder.Builde_Rebar();//建造钢筋
abstractBuilder.Builde_Floor();//建造楼层
abstractBuilder.Builde_Electricity();//电力完成
abstractBuilder.Builde_Water();//水源完成
House temp = abstractBuilder.Builde_House();//成品房屋完成
this.Log($"完全品{temp}完成");
return temp;
}
}
调用
public class BuilderComponent : MonoBehaviour
{
void Start()
{
AbstractBuilder abstractBuilder = new BuilderHouse();
Director director = new Director(abstractBuilder);
House house = director.GetResult();
}
}
打印信息
总体上代码还是很简单的，下面笔者就和大家具体的分析一下这个建造者，其实这个抽象工厂模式特别的相似，也都是创建产品,但是建造者模式只是把原来有工厂直接创建的函数交给了Director来执行。如果当时我要是命名的话可能叫【AbstractFactoryPlus】，在写法上看就是让多行的创建代码演变成现在的
Director director = new Director(abstractBuilder);与House house = director.GetResult();，从结构上看是把原本的创建过程再次的封装和转移，如果想修改创建过程可以直接在Director类中修改。最后通过Director组装，在组装的过程中可以不断的像一个容器内添加，获取最终的产品。
从职责划分上看：【抽象工厂】主要是没有元素或者说一个元素对应一个产品，以这种模式产出多个产品。【建造者模式】是多个元素建造一个产品。目的关心的是一个产品复杂的生产过程（过程再次封装转移）。
笔者认为，如果创造过程相对简单，可能2-5行代码可以解决的问题其实就用工厂就可以了，如果十分复杂的创建就可以考虑下建造者模式
建造者模式的好处就是使得建造代码与表示代码分离，由于建造者隐藏看了该产品是如果组装的，所以若需要改变一个产品的内部表示，只需要再定义一个具体的建造者（示例中的BuilderHouse）就可以了。
指挥者（Director）主要是用于创建一些复杂的对象，这些对象内部构建件的建造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。不过真的需要建造顺序更改时，我们也可以重新定义一个新的Director，只需要把原有的Director类替换掉就可以，上层的改动也相对较小，绝对的开闭原则是不存在的，相对的开闭才是我们应该掌握的。
也有人问过笔者，为什么不用接口替换掉对应的
AbstractBuilder呢？笔者是这样理解的，接口是一个独立的功能，不是一个系统，就拿移动电话为例：它含有上网、听音乐、看电影、储存、拍照、收发信息等功能，每一个功能都可以是一个接口，且这种接口具有通用性，问什么说是通用性？例如上网功能接口电脑也可以继承，拍照这种功能接口专业摄像机也可以继承这就是通用性。这种微小独立功能的划分也符合接口隔离原则。
但是抽象类呢，他更像一个特殊的缩小系统，就像手机是众多电子产品中的一种，但是手机的品牌很多，基于这种缩小系统基本一致性的特点，不同的品牌，我们就可以根据手机抽象类实现不同的品牌实例。而且在抽象基类里面可以实现一些字段和函数，接口则不能。
List这种就是集各种通用功能于一身的
这种文件操作的抽象类就很局限了
最后要说的是笔者可能会停更一段时间，因为最近一直在找工作，对于这种结构上的东西【HR】和面试官貌似都不感兴趣，所以笔者目前不想在这个上面花费更多的时间了，非常感谢大家一直对海澜的帮助，由衷的感谢~ 找到工作我还会回来的
网友评论