工厂模式

工厂是什么东东？帮我们管理产品的地方。
产品是什么东东？我们想要的对象实例。

为什么不自己直接取产品（即 new 一个自己想要的对象实例）？
通过工厂来取产品（即 工厂创建并返回对象实例给我们）有什么好处？

思考：哪一天，我们想要的产品发生了点变化，比如昨天要的是长毛大衣，今天想换成雪纺裙子。那怎么更改？

1. 直接去产品堆中创建一中雪纺裙子类型，然后客户端（Main函数里）的创建大衣类型换成雪纺裙子类型 ps：客户端要改得是不是太多了呢，我只是换了个条件，要的还是衣服啊，衣服功能都还差不多
2. 直接把大衣类型的构造换成雪纺的，改改类型名字使得语义良好，客户端也改改原来创建的大衣类型实例 ps：自己客户端改得多了也就算了，连大衣模型都给弄没了，别的要大衣的客户端不得上吊

既然这样操作不太好，要不来个专门管理衣服的工厂，客户端换个条件，然后工厂给我换件合适的衣服。这样的好处？

1. 客户:创建的类型还是衣服类型，功能不变（不考虑那些什么额外的是否保暖的，是否可以用来防止走光的…），只是拿的衣服布料变了,那就传个衣服条件给工厂（可能换间工厂）
2. 工厂:看看本来有没有这种雪纺衣服类型，有的话，直接给客户？没有的话，可以考虑创建新的衣服类型，是个发展商机，便于发展更多客户，哈哈（简单工厂模式）。又或者新开一家工厂来专门管理者种衣服的（工厂模式）。

思考：为什么新建一家工厂发一种不同类型的衣服更好，而不是在一个发衣服的工厂发各种衣服类型？ 有时候这件衣服可能不单单根据一个原型来造，可能会有各种加工，例如配个纽扣什么的（更容适应客户端的需求变化，而又不容易影响别的改变）。

进入正文咯、、、

简单地说，客户端使用工厂来创建产品的实例。工厂抽取了客户端原本的创建和初始化产品的功能，从而客户不必关心产品创建的细节。

以下是MSDN官方例子解析：

  abstract class Computer //明确电脑的基本功能    {        public abstract int Mhz { get; }    }//Computer    abstract class ComputerFactory  //明确工厂的基本功能就是发货（在这儿 货就是电脑）    {        public abstract Computer GetComputer();    }//ComputerFactory

 class ConcreteComputer : Computer //具体的电脑实现    {        int _mhz = 500;        public override int Mhz        {            get { return _mhz; }        }//Mhz    }//ConcreteComputer    class ConcreteComputerFactory : ComputerFactory //具体某种类型电脑发货工厂    {        public override Computer GetComputer()        {            return new ConcreteComputer();        }//GetComputer    }//ConcreteComputerFactory

 class ComputerAssembler  //电脑装配工     {        public void AssembleComputer(ComputerFactory factory)        {            Computer computer = factory.GetComputer();            Console.WriteLine("assembled a {0} running at {1} MHz",               computer.GetType().FullName, computer.Mhz);        }//AssembleComputer    }//ComputerAssembler

 class Program  //客户    {        static void Main(string[] args)        {            ComputerFactory factory = new ConcreteComputerFactory(); //指定工厂            new ComputerAssembler().AssembleComputer(factory); //去叫电脑装配工根据工厂取货        }    }

写得不怎么专业，也可能思想偏移。