标签：
What:
SimpleFactroyPattern，由一个工厂类根据传入的参数，动态的决定创建哪一个产品类（这些产品类继承自一个类或者接口）。
Why：
封装创建对象的细节，客户端调用时只需要关注所需的对象，而不必关心创建的细节，减少类之间的依赖。
How：
简单工厂中包含的角色及其职责
工厂类（Factory）：简单工厂模式的核心，负责实现创建所有势力的内部逻辑，工厂类可以直接由外接调用以创建所需的对象。
抽象产品类（Product）：简单工厂模式中所有具体产品类的父类，它负责描述所有实例共有的特性及行为。
具体产品类（ConcreteProduct）：简单工厂模式中创建咪表，所有创建的对象都是充当这个觉得的某个具体类的实例。
使用简单工厂模式前：类图如下所示，客户端对于具体产品类的依赖性很强。
假设现在有这么一个情景：现在有一家公司老板想要听取一下几个岗位对于公司未来的发展的看法，所以需要不同岗位的员工谈一下相关的看法板，老板分析一下各岗位员工对于公司发展前景的看法。
在现实的生活当中，稍微大一点的企业，老板都是会有助理的，老板告诉助理，然后让助理去通知各个员工。其实在这里老板就是客户端，秘书就是工厂类，员工是抽象产品类，具体岗位的员工就是具体产品类。
如果没有秘书，老板要怎么做？老板需要知道各个岗位的相关员工，然后通知他们完成这么一项任务，那么公司各个岗位员工老板都必须要清楚，而且要清楚他们的联系方式，再一一通知相关的员工，如果现实中老板这样事必躬亲，那得到了员工的意见，估计也不会有太多的时间思考公司怎么发展。
那么我们增加了一个老板助理会有什么好处呢？由秘书来完成通知员工的细节，里面怎么喊道相关员工由秘书来完成，老板不必关心，只需要告诉秘书现在需要哪个岗位的人来面谈，哪个岗位就是这里传入工厂方法的参数了。
使用工厂模式后：客户端对于具体产品类不再依赖，达到解耦的目的。
抽象产品类：员工类
abstract class Employee { //提出意见 internal abstract void PutForwardSuggestions(); }
具体产品类：工程师
class Engineer : Employee { internal override void PutForwardSuggestions() { Console.WriteLine("工程师代表意见：定期进行技能培训，提升员工的业务水平"); } }
具体产品类：财务
class Accountant : Employee { internal override void PutForwardSuggestions() { Console.WriteLine("财务代表意见：引入财务软件，将使公司的财务管理更加的方便"); } }
工厂类：秘书
class Assistant { //找到老板制定岗位的员工 internal static Employee LookForEmployee(string positionName) { Employee result = null; if (positionName == "engineer") { result = new Engineer(); } else if (positionName == "accountant") { result = new Accountant(); } return result; } }
客户端调用：
class Program { static void Main(string[] args) { Employee firstEmpolyee = Assistant.LookForEmployee("engineer"); firstEmpolyee.PutForwardSuggestions(); Employee secondEmpolyee = Assistant.LookForEmployee("accountant"); secondEmpolyee.PutForwardSuggestions(); Console.ReadLine(); } }
运行结果：
简单工厂模式的缺点：所有的创建逻辑集中在工厂类中，随着具体产品类不断的增加时，每一次都需要对工厂类进行修改，违反了开放封闭原则，扩展性不好。
标签：
原文地址：http://www.cnblogs.com/XzcBlog/p/4221653.html
