制作工序都是：请洗，加工，上菜,恩定义一个接口

public interface IFish
{
    string wash();
    string machining();
    string serving();
    string price();
}

烤鱼：

public class BakeFish:IFish
{
    private string fishType = "鲢鱼";//默认处理的,这部分以后会扩展[扩展什么?如果客人指定鱼呢?那价格不同把,呵呵,恩if判断,那在加一种鱼呢?恩,加if...天那,我又想去揍那个客户了,简直哭笑不得,"笑",噢,对了,笑,上一个客户你怎么解决的,策略模式,我们把价格计算独立出来,再根据实际需要组合.到这里你是不是想感想前一个客户了,对,带给你经验的往往就是客户,他们给公司带来钱,给你带来经验,无论你多么想揍他,还是先忍忍把..突然想起来,你看猎人吗?呵呵,可能你会想会长一样,发现充满的竟是感想.好了先跳过把],现在客户认为烤鲢鱼最好.
 public BakeFish()
 {
 }
    public string FishType
    {
        set { fishType = value; }
        get { return fishType; }
    }
    public string wash()
    {
        return "washing BakeFish";
    }
    public string machining()
    {
        return "machining BakeFish";
    }
    public string serving()
    {
        return "serving BakeFish";
    }
    public string price()
    {
        return "$30";
    }
}

水煮鱼：

public class WaterFish:IFish
{
    private string fishType = "草鱼";//默认
 public WaterFish()
 {
 }
    public string FishType
    {
        set { fishType = value; }
        get { return fishType; }
    }
    public string wash()
    {
        return "washing WaterFish";
    }
    public string machining()
    {
        return "machining WaterFish";
    }
    public string serving()
    {
        return "serving WaterFish";
    }
    public string price()
    {
        return "$35";
    }
}

清蒸鱼:
public class BraiseFish:IFish
{
    private string fishType = "鲫鱼";//默认
 public BraiseFish()
 {
 }
    public string FishType
    {
        set { fishType = value; }
        get { return fishType; }
    }
    public string wash()
    {
        return "washing BraiseFish";
    }
    public string machining()
    {
        return "machining BraiseFish";
    }
    public string serving()
    {
        return "serving BraiseFish";
    }
    public string price()
    {
        return "$40";
    }
}

恩,都定义好了,那接着就到客人点菜了..那我们想来直接new一下试试吧,看看怎么用的:

IFish fish=null;
        if (this.DropDownList1.SelectedValue == "BakeFish")
        {
            fish = new BakeFish();
        }
        else if (this.DropDownList1.SelectedValue == "BraiseFish")
        {
            fish = new BraiseFish();
        }
        else if (this.DropDownList1.SelectedValue == "WaterFish")
        {
            fish = new WaterFish();
        }
        Response.Write(fish.wash() + "<br>");
        Response.Write(fish.machining() + "<br>");
        Response.Write(fish.serving() + "<br>");
        Response.Write(fish.price() + "<br>");

恩...这样就行了..可以如果以后这间餐厅发展了,想多加一种菜你就不得不修改这里了...如果只有这里那还好,假如订餐的时候需要判断一次,把订单拿到柜台正式下单的时候又要判断一下,送进厨房的时候又要判断一下...恩..那就要在3处加入新菜了[修改代码]...好了,看到这里是变化的,那我们就把他那出来单独处理把..我们建一个类来处理对象的创建

public class SimpleFishFactory
{
    public SimpleFishFactory()
 {
 }
    public IFish CreateInstance(string type)
    {
        if (type == "BakeFish")
        {
            return new BakeFish();
        }
        else if (type == "BraiseFish")
        {
            return new BraiseFish();
        }
        else if (type == "WaterFish")
        {
            return new WaterFish();
        }
        else
        {
            return null;
        }
    }
}

好了..我们建立了一个简单工厂,用他来负责对象的创建,看看客户程序变成什么样拉

SimpleFishFactory factory = new SimpleFishFactory();
        IFish fish = factory.CreateInstance(this.DropDownList1.SelectedValue);
   
        Response.Write(fish.wash() + "<br>");
        Response.Write(fish.machining() + "<br>");
        Response.Write(fish.serving() + "<br>");
        Response.Write(fish.price() + "<br>");

ok,这就是简单工厂了,虽然这并还不是一种设计模式,不过已经可以帮你封装一部分的变换了.如果要加入鱼的新做法,那我们修改一些SimpleFishFactory 就行了,客户端的多处调用不用动了,为什么?因为客户端我们依赖于接口了,而不是依赖与具体的实现类了.设计原则之一:依赖于接口而不要依赖于具体的实现,这里的接口包括[接口和抽象类,呵呵,我只知道这两种了]

好了..继续把..很偶然的...这里的人很喜欢吃鱼,这家餐厅继续扩大了..现在客户要我们为菜提供不同的地方口味[其实这里加入装饰模式可能更好点,不过我们继续我们的工厂把,以后我们再会到这里改把],区别是machining的不同了..好了,客户的要求是他们要加入四川和广东的口味,ok,那我们扩展"鱼"把.
public class GDWaterFish//广东风味的.
{
 private string fishType = "草鱼";
    public GDWaterFish()
 {
 }
    public string FishType
    {
        set { fishType = value; }
        get { return fishType; }
    }
    public string wash()
    {
        return "washing WaterFish";
    }
    public string machining()
    {
        return "machining WaterFish";
    }
    public string serving()
    {
        return "serving WaterFish";
    }
    public string price()
    {
        return "$35";
    }
}
public class SCWaterFish:IFish//四川风味的.
{
    private string fishType = "草鱼";
    public SCWaterFish()
 {
 }
    public string FishType
    {
        set { fishType = value; }
        get { return fishType; }
    }
    public string wash()
    {
        return "washing WaterFish";
    }
    public string machining()
    {
        return "machining WaterFish";
    }
    public string serving()
    {
        return "serving WaterFish";
    }
    public string price()
    {
        return "$35";
    }
}
到这里,如果我们还是用简单工厂的话,每次加入新的风味的话,那每次都要修改简单工厂了.虽然我们只需要修改一个地方,不过呢,记住对修改封闭,对扩展开放的原则,能不修改的我们就不修改.那好吧,你只能去百度,google了...呵呵,然后你可能会发现工厂模式,哦~它可以帮我解决这个难题.好,都是工厂嘛,我们就从简单工厂转换成工厂把.
首先,习惯是依赖于抽象,所以我们先建立一个抽像类把
public abstract class AFactory
{
    private IFish fish=null;
 public AFactory()
 {
 }
    public string display()
    {
        fish = CreateFish();
        return fish.wash() + "<br>" + fish.machining() + "<br>" + fish.serving() +"<br>" + fish.price();
    }
    public abstract IFish CreateFish();
}
然后还要一系列的子工厂负责具体对象的创建:就只列出几个把...
public class GDBakeFishFactory : AFactory
{
    public GDBakeFishFactory()
 {
 }
    public override IFish CreateFish()
    {
        return new GDBakeFish();
    }
}
public class GDBraiseFishFactory:AFactory
{
    public GDBraiseFishFactory()
 {
 }
    public override IFish CreateFish()
    {
        return new GDBraiseFish();
    }
}
public class GDWaterFishFactory:AFactory
{
    public GDWaterFishFactory()
 {
 }
    public override IFish CreateFish()
    {
        return new GDWaterFish();
    }
}
....等等..等等..为每一个对象建一个工厂?那不是让程序更复杂了,对的,这里你或许可以用简单工厂加工一下,或许我们就不用建那么多工厂了.不过工厂模式负责的是单个对象的创建,并将创建延迟到之类,同时他会带来和类平行的结构图.现在你想想加入一个做法,就加入一个工厂那是不是不会影响到其他的东西呢?所以我们做到封装了,可以扩展,而不用去修改.恩看看客户程序的调用把.
哦,对了,虽然客户程序只知道需要取得"鱼",并别需要取得什么鱼到什么工厂里取就可以了,不过还是有逻辑上的判断的,例如客户程序说要广东的清蒸鱼,那你还是要去广东清蒸鱼的工厂里取的,那不是只不过将鱼到具体鱼的依赖转变成鱼和具体工厂的依赖了吗?
我们先看看客户程序把:我们的客人要指定广东清蒸鱼
AFactory factory = new GDBraiseFishFactory();//可是客户程序和具体工厂耦合了.
        IFish fish = factory.CreateFish();//我们把鱼和具体鱼的耦合在客户程序解开了
        Response.Write(fish.wash() + "<br>");
        Response.Write(fish.machining() + "<br>");
        Response.Write(fish.serving() + "<br>");
        Response.Write(fish.price() + "<br>");
这样能带来什么好处呢?
1.假如需要对鱼再加工把,在这里GDBraiseFishFactory加工,鱼基本做法不变,客户程序不变.//假如这是逻辑层的话,那数据层不变,表现层[客户程序]不变.如果我们依赖于具体的鱼的话,那如果需要再加工的话,那我们需要在客户程序进行,并且不只一处.简单工厂?那每次加入新的变化都需要修改,说明没有对修改封闭,那可能会对以前的逻辑造成错误,产生bug..
2.需要加入其他烹调法,加入新的factory,新的类,以前的鱼和工厂不变,不用修改就是减少修改带来的bug,上一点应该是比较主要的..

好了,我也是半理解半不理解之间把,只能说到这里了..接着,到抽象工厂了,我们的餐厅继续扩大.它要杀出中国了,又会带来变化.先说一下工厂和抽像工厂把.
1工厂解决的是单个对象的创建.
2抽象工厂解决的是一系列相互依赖的对象的创建.
你可以在工厂中加入简单工厂从而减少工厂的膨胀,那样是不是看起来好像是一系列的对象呢?其实他一个时刻只能返回一个对象,而不是返回一系列的对象.但抽象工厂是可以给你在一个初始化中提供一系列对象的.
本来想一口气写完的...看来太多的..受不了了....=_=...

 例子

   可惜的是当你接触设计模式以后你可能会看到的一个原则，“多用组合，少用继承”，为什么呢，接着就从代码开始说把，一些的例子纯属假设性成立的情况下的。。呵呵。

   现在你的客户要你写个小东西，用来描述人的。人肯定会有共同的行为了，例如”笑“把，恩，具体什么人先不理了，我现在想到的是，人都会”笑“，美女可能笑的好看点~呵呵。所以先定义一个父类把。我们在给“人”加几种属性的描述；

public class Person
{
 public Person()
 {
  //
  // TODO: 在此处添加构造函数逻辑
  //
 }
    protected string sex=string.Empty;
    protected string name = string.Empty;
    protected int age;
    public string Sex
    {
        get { return sex; }
        set { sex = value; }
    }
    public string Name
    {
        get { return name; }
        set { name = value; }
    }
    public string Age
    {
        get { return age; }
        set { age = value; }
    }
    public string Laugh()
    {
        return "laugh ^_^";
    }
}

好了，“人的共有属性和一个行为”我们定义完了，然后我们加入个美女把，^_^,当然她也是属于人这个种族的了。。。。所以她肯定继承了人的属性和方法了。

public class Girl:Person
{
 public Girl()
 {
  //
  // TODO: 在此处添加构造函数逻辑
  //
 }
}

一个不能说明什么把，那我们在加入些别的把。。。

public class Boy:Person
{
    public Boy()
 {
  //
  // TODO: 在此处添加构造函数逻辑
  //
 }
}

public class Baby:Person
{
 public Baby()
 {
  //
  // TODO: 在此处添加构造函数逻辑
  //
 }
}

恩，好了，都加上了，然后我让他们笑一下把

Girl a = new Girl();
Boy b = new Boy();
Baby ba = new Baby();
Response.Write(a.Laugh());
Response.Write(b.Laugh());
Response.Write(ba.Laugh());

输出：laugh ^_^laugh ^_^laugh ^_^，恩，都笑了，虽然后边两个我没什么兴趣看到。。。不过都笑了。=_=..是不是看到继承的强大了呢？子类里我们可是什么都没写呀。恩，我们可以交差了。

    可是，有一天这个让人头疼的客户突然想到。。不能是一样的笑呀。。。要让美女”微笑“，让男生“狂笑”，让小孩”傻笑“，让XX“X笑”，他还想加入“去世的人”这中类别。。。你一听是不是也开始笑了。。。对，继承会让死人也笑的，好吧，我覆盖掉父类的方法把。让具体的人去实现具体的笑法。。

public class Girl:Person
{
    public override string Laugh()
    {
        return "smile";
    }
}

public class Boy:Person
{
    public override string Laugh()
    {
        return "guffaw";
    }
}

。。。。。。。。。。。

好了，改完了。。。各笑各的去吧。。。你也可以笑了。。。可是客户还没笑呢。当你那去交工的时候，他突然对你说，还不行。他想让美女能微笑也能傻笑~^_^...好了，如果你可以得罪他就给他一拳把。。。不行？那回去继续改把。。怎么改呢，好吧继续还是继承把。。。然后我在子类中扩展其他的行为。如果你不怕那个客户又出新花招的话。。那就这样该把。如果你怕了的话，恩，那开始考虑不用这样直接的继承了把。考虑用别的方式去实现把。。。或许你会想到的是围绕的就是”笑“这个行为出现的变化，那可不可以不要在继承中具体实现继承这个行为呢？如果我们在继承中定义了是人的属性，然后把”笑“这个行为拿出来，具体的时候再组装不就行了。。到时你的客户想让谁怎么笑就怎么笑了。。所以从父类开始下手把。先把集体的实现类改成抽像类

public abstract class APersons
{
    protected string sex=string.Empty;
    protected string name = string.Empty;
    protected int age;
    protected IAction action;//加入了一个行为的接口
    public IAction Action//指定具体的行为：我们这里当然是怎么“笑”了。。
    {
        get
        {
            return action;
        }
        set
        {
            action = value;
        }
    }
    public abstract string PerformLaugh();//子类在具体实现笑把。
}

然后加入这个行为的接口把

public interface IAction
{
    string Laugh();
}

方正现实了这个接口的行为都要笑。。怎么笑就不理他了。。继续写实现了接口的行为类。。。

public class smile : IAction
{
 public smile()
 {
 }
    public string Laugh()
    {
        return "smile ^_^";
    }
}

public class guffaw:IAction
{
 public guffaw()
 {
 }
    public string Laugh()
    {
        return "guffaw ^_^";
    }
}

然后测试一下把：先测试美女~

        APersons f = new Female();
        f.Action = new smile();
        Response.Write(f.PerformLaugh()+"微笑<br>");
        f.Action = new guffaw();
        Response.Write(f.PerformLaugh() + "狂笑ing<br>");
        f.Action = new giggle();
        Response.Write(f.PerformLaugh() + "傻笑<br>");

输出：

smile ^_^微笑
guffaw ^_^狂笑ing
giggle ^_^傻笑

再试试小破孩。。。

APersons f = new Child();
        f.Action = new smile();
        Response.Write(f.PerformLaugh()+"微笑<br>");
        f.Action = new guffaw();
        Response.Write(f.PerformLaugh() + "狂笑ing<br>");
        f.Action = new giggle();
        Response.Write(f.PerformLaugh() + "傻笑<br>");

输出：

smile ^_^微笑
guffaw ^_^狂笑ing
giggle ^_^傻笑

好了。这样就把属性和行为分离开了。。如果客户要多几种笑法也很容易加了，想让谁怎么笑也能了。。。如果他笑了，你也能“笑”了。。

这个好像就是策略模式了把。。。呵呵。。 感觉呢，做项目就是在挖坑埋自己。。。。。如果你有足够的经验和预见的能力，良好的设计会成为你的救命稻草。所不定那一次很突然能把你从坑里拉出来，不然，呵呵，可能会埋完自己一次又一次的。。如果你已经习惯被埋了。。那恭喜你了。。实在太强大了。。我现在是看着前边挖的坑就头痛。。。。=_=

    例子