简单工厂模式

 本人已经博客移至南京交通设施有限公司：从设计模式的类型上来说，简单工厂模式是属于创建型模式，又叫做静态工厂方法（Static Factory Method）模式。

 

此模式一般用于实例化类，通过一个参数确定所要是实例化的类。

 

在此模式中，存在着一个工厂类，他负责对整个模式进行控制。在此类中存在逻辑判断，根据接收到的参数进行判断，从而返回实例化后的对象。

 

 

工厂（Factory）角色：接受客户端的请求，通过请求负责创建相应的产品对象。

抽象产品（AbstractProduct）角色:是工厂模式所创建对象的父类或是共同拥有的接口。可是抽象类或接口。

 具体产品（ConcreteProduct）对象：工厂模式所创建的对象都是这个角色的实例。

 

For example:

当我们在买早餐的时候，早餐店里都卖得写什么呢？这点你有注意吗？众多食品摆在那里，你只对营业员说你要何种食品，他便会知道给你拿什么样的食品给你，这说明什么呢？如果用面向对象的思想来理解的话，营业员在这里就充当了一个工厂的角色，他负责根据你的请求返回你需要的食品对象。而这一点正是简单工厂模式的意图。     

具体实现算法如下：

1. 首先编写一个食物基类（Food）这是角色中的抽象产品，他表示工厂所要返回的对象的共有特征。然后根据食物类派生其他类，比如馒头类(Bread)，包子类(Dumpling)，油条类（Stick）。这是所要返回的实例化类。

2.编写工厂角色类(Factory)。函数public static Food CreateInstance(string key)根据参数key进行逻辑判断，返回所要实例化的对象。

3. 编写客户端程序，调用工厂类中的CreateInstance函数。返回一个FOOD的子类。由于可用父类表示子类，所以……

 

 

   此时的设计就已经完全符合简单工厂模式的意图了。顾客(Client)对早餐店营业员(Factory)说，我要“馒头”，于是营业员便根据顾客所提供的数据（馒头）,去众多食品中找，找到了然后就拿给顾客。

 

 

优缺点：

1. 工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅"消费"产品。简单工厂模式通过这种做法实现了对责任的分割。
2. 当产品有复杂的多层等级结构时，工厂类只有自己，以不变应万变，就是模式的缺点。因为工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
3. 系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，有可能造成工厂逻辑过于复杂,违背了"开放--封闭"原则(OCP).另外，简单工厂模式通常使用静态工厂方法，这使得无法由子类继承，造成工厂角色无法形成基于继承的等级结构。