C#描述设计模式(3):创建者模式学习心得

创建者模式学习心得

某个东西需要由其他的东西组合而成。

如中国移动的套餐，套餐A是由短信包1和长话包2组成的；套餐B是由短信包2和长话包3组成的。

适合应付这样的变化：如果套餐的数目不确定，并且里面的包的数目和类别也不确定。

比如中国移动的套餐随着时间的变化，需要不断变化，并且不断推出新的套餐品种。

 
一个人要去找工作，首先要选择一个合适的套装（Suit）。

而套装又是由上衣（Jacket）、裤子（pants）和鞋子（Shoe）组成的。 

他要根据不同的工作性质选择不同的衣服。 

1。需要穿衣服的人：Client 

2。指导它穿哪套套装的对象:Director 

3。A套装的构造者：ABuilder,B套装的构造者：BBuilder,C套装的构造者：CBuilder 
和他们继承的接口：IBuilder 

4。套装：Suit 

5。上衣：Jacket、裤子：pants、鞋子：shoe 

类的关系图：图1 

1。Client的职责是选择一种套装。client需要输入他所选择的套装类型。 

classClient
...{
staticvoidMain(string[]args)
...{
//testBuilderPattern
Directordirector=newDirector();
IBuilderbuilder;
Console.WriteLine("inputyourchoice:A,BorC?");
stringSignal=Console.ReadLine();
builder=director.ConstructSuit(Signal);
Suitsuit=builder.GetSuit();
suit.Show();

Console.ReadLine();
}
}

2。Director的职责是找出可以创建该套装的“创建者”。 

他是沟通Client的需求和“创建者”工作的一个中间环节。 

publicclassDirector
...{
publicIBuilderConstructSuit(stringSignal)
...{
switch(Signal)
...{
case"A":...{returnnewABuilder();}
case"B":...{returnnewBBuilder();}
case"C":...{returnnewCBuilder();}
default:returnnull;
}



}
}

3。ABuilder、BBuilder、CBuilder均实现IBuilder的接口， 
用来创建A种的Suit、B种Suit、C种Suit。 

publicinterfaceIBuilder
...{
SuitGetSuit();
}

publicclassABuilder:IBuilder
...{
publicSuitGetSuit()
...{
JacketjacketA=newJacket("A");
PantspantsA=newPants("A");
ShoeshoeA=newShoe("A");

SuitsuitA=newSuit(jacketA,pantsA,shoeA);
returnsuitA;
}
}
publicclassBBuilder:IBuilder
...{
publicSuitGetSuit()
...{
JacketjacketB=newJacket("B");
PantspantsB=newPants("B");
ShoeshoeB=newShoe("B");

SuitsuitB=newSuit(jacketB,pantsB,shoeB);
returnsuitB;
}
}

publicclassCBuilder:IBuilder
...{
publicSuitGetSuit()
...{
JacketjacketC=newJacket("C");
PantspantsC=newPants("C");
ShoeshoeC=newShoe("C");

SuitsuitC=newSuit(jacketC,pantsC,shoeC);
returnsuitC;
}
}

4。套装类。他的职责是规范一个套装应该有的三个部分，并且根据这三个部分创建出套装 

publicclassSuit
...{
JackettheJacket;
PantsthePants;
ShoetheShoe;


publicSuit(Jacketjacket,Pantspants,Shoeshoe)
...{
theJacket=jacket;
thePants=pants;
theShoe=shoe;
}
publicvoidShow()
...{
theJacket.show();
thePants.Show();
theShoe.Show();

}
}

5。裤子、衣服和鞋子，均是最基本的构成，职责是通过传入的 参数构造出一个自己： 

publicclassJacket
...{
publicstringJacketType;
publicJacket(stringjacketType)
...{
JacketType=jacketType;
}
publicvoidshow()
...{
Console.WriteLine("I'm"+JacketType+"jacket");
}
}
publicclassPants
...{
publicstringPantsColor;
publicPants(stringpantsColor)
...{
PantsColor=pantsColor;
}
publicvoidShow()
...{
Console.WriteLine("I'm"+PantsColor+"colorPants");
}

}
publicclassShoe
...{
publicstringShoeSize;
publicShoe(stringshoeSize)
...{
ShoeSize=shoeSize;
}
publicvoidShow()
...{
Console.WriteLine("I'mShoeof"+ShoeSize);
}
}

按照传统的思维，我们会这样处理这个问题： 

创建一个Suit的父类，然后不断的继承它，从而创造出A、B、C三种套装。 

client根据自己的需求，来选择实例化不同的套装。 

但是这样有什么缺点呢？ 

1。使用创建者模式的时候，Client并不必知道Suit这个东西，它只面对Director， 

它只需要知道到底是A、B还是C。他不用关心到底是Suit还是Coad，或者是其他什么东西。 

如果说在构造套餐之外，有其他的需求是和A、B、C的选择相关的，就可以体现出创建者模式的优势。 

比如，A表示“严肃”系列，适合应聘行政工作；B表示“休闲”系列，适合应聘美工。 

Client在对Director作出A、B的选择后，除了获得了一个合适的Suit，还需要获得一份“面试指导”。 

这时候Director就可以调用其他对象了 

2。builder之间更加松耦合。相对于传统的方法，它和Suit的关系是“使用”，而不是“继承”。 

3。构造的过程可以更加精细控制。比如说，某种Suit不需要shoe了，它只要有jacket和pants就可以了。

 
它可以先构造jacket，也可以先构造shoe。。。 

4。构建代码和表现代码分离。构造是在Builder类里面实现的，而表现是由suit实现的。 

这样实现了控制和表现的分离。 

5。不同的suit只是不同jacket、pants和shoe的排列组合而已，从概念上说不是继承的关系。 

1。builer的重点是在不同的请求下，给出不同的排列组合。 

Factory的重点是在不同的请求下，给出不同类的实例。 

2。Builder不需要一个抽象的Suit。而用工厂就需要了。 

附：用工厂实现这个需求的类图：图2 

这样的场景比较适合使用工厂：一个人要选择面试的裤子：它如果选A就给Apants，选B就给Bpants。。。 

其中，Director可以采用映射生成一个实例 
这样的话，Director中就不需要出现A、B的字眼了。

publicclassDirector
...{
publicIBuilderConstructSuit(stringSignal)
...{
//switch(Signal)
//{
//case"A":{returnnewABuilder();}
//case"B":{returnnewBBuilder();}
//case"C":{returnnewCBuilder();}
//default:returnnull;
//}

return(IBuilder)Assembly.Load("ConsoleApplication1").CreateInstance("BuilderPattern."+Signal+"Builder");

}
}

这个模式的应用范围非常广。这种类似于“套餐”的 都可以应用。 

1。用户页面的定制。 

2。自动生成网站系统中的页面布局。如果可以做成这样的话，那网站只需要一个页面 了 
根据它的需求定制它的控件就可以了。 

3。DataList的建造 

4。用户订阅不同的信息，其实也是套餐。