建造者模式

  在系统开发中经常会遇到组建复杂的对象，如果该复杂的对象是由一些小的对象组成而且这些小的对象的业务组成逻辑相对稳定，同时如果业务逻辑改变则改变小对象的组合逻辑又可以产生一个新的符合对象此时可以考虑用建造者模式来说实现建造者和被建造者之间的解耦。

  意图

   将建造与表示分开，使得建造和表示解耦。

模型

建造者角色  给出一个抽象接口，以规范产品对象的各个组成成分的建造，一般而言此接口独立于应用程序的商业逻辑，具体的建造者中必须实现两个方法，一个是构造方法，另一个是结果返回方法。

具体建造者角色  完成产品实例的构建，提供产品实例的展示

指导者  调用产品构建对象通知产品构造对象构造某种业务类型的产品；

产品  构造中的复杂对象。

下面以湖南人到餐馆吃饭为例写一段代码我们首先不考虑设计模式一步一步的重构

public class restaurant

{

　　public void stir_frying()

　　{

　　　　Console.writele("我要加辣;");

　　}

} 

下面我们来看客户端实现

public class Client

{

　　restaurant rtt = new restaurant();

　　rtt.stir_frying();

}

这样写没什么问题，可是当有个一个广东人来餐馆吃饭这时候广东人不吃辣的怎么办，在里面在加一个方法但是这个时候违反啦开放闭合原则，现在我们针对我们的需求来重新设计代码

我们这里业务改变点是炒菜的需求增加，我们现有的设计无法满足现在的需要于是改变炒菜类

public abstract class arestaurant

{

　　abstract void stir_frying();

}

 

此时当需要增加一种菜系的时候就可以增加一个子类，比如现在有一个广东人来啦那么我们可以这样写

public class arestaurantgd:arestaurant

{

　　public overrid stir_frying()

　　{

 

　　　　　Console.WriteLine("我不要辣椒!");

　　}

}

现在我们用构造模式来构建这个代码

public abstract class arestaurant

{

　　abstract void stir_frying();

}

 

public class arestaurantgd:arestaurant

{

　　public overrid stir_frying()

　　{

　　　　　Console.WriteLine("我不要辣椒!");

　　}

}

 

public class arestaurantgd:arestaurant

{

　　public overrid stir_frying()

　　{

　　　　　Console.WriteLine("我要辣椒!");

　　}

}

public class FoodManager

{

　　public void Construct(arestaurant att)

　　{

　　　　att.stir_frying();　

　　}

}

 

public class client

{

　　FoodManager foodmanager = new FoodManager();

　　foodmanager.Construct(new arestaurantgd())

}

这是一个简单的事例客户端还有待改进，我这里简化啦子元素的构建，有待改进；