文章很长很精彩，如是初学请耐心观看。（大神请绕道！）
简单工厂模式:
1.创建型模式
2.简单工厂模式概述
3.简单工厂模式的结构与实现
4.简单工厂模式的应用实例
5.创建对象与使用对象
6.简单工厂模式的简化
7.简单工厂模式的优缺点与适用环境
1.创建型模式(Creational Pattern):
关注对象的创建过程 创建型模式对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离，对用户隐藏了类的实例的创建细节 创建型模式描述如何将对象的创建和使用分离，让用户在使用对象时无须关心对象的创建细节，从而降低系统的耦合度，让设计方案更易于修改和扩展. (创建型模式的关注点:1.创建什么? 2.由谁创建? 3.何时创建?)
| 模式名称 | 定义 | 学习难度 | 使用频率 |
|
简单工厂模式 (Simple Factory Pattern) |
定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。 | ★★☆☆☆ | ★★★☆☆ |
|
工厂方法模式 (Factory Method Pattern) |
定义一个用于创建对象的接口，但是让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。 | ★★☆☆☆ | ★★★★★ |
|
抽象工厂模式 (Abstract Factory Pattern) |
提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。 | ★★★★☆ | ★★★★★ |
|
建造者模式 (Builder Pattern) |
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 | ★★★★☆ | ★★☆☆☆ |
|
原型模式 (Prototype Pattern) |
使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象。 | ★★★☆☆ | ★★★☆☆ |
|
单例模式
(Singleton Pattern) |
确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例。 | ★☆☆☆☆ | ★★★★☆ |
2.简单工厂模式概述:
简单工厂模式基本实现流程
具体产品类：将需要创建的各种不同产品对象的相关代码封装到具体产品类中
抽象产品类：将具体产品类公共的代码进行抽象和提取后封装在一个抽象产品类中
工厂类：提供一个工厂类用于创建各种产品，在工厂类中提供一个创建产品的工厂方法，该方法可以根据所传入参数的不同创建不同的具体产品对象
客户端：只需调用工厂类的工厂方法并传入相应的参数即可得到一个产品对象
1 if(arg.Equals("A")) 2 { 3 return new ConcreteProductA(); 4 } 5 else if(arg.Equals("B")) 6 { 7 return new ConcreteProductB(); 8 } 9 else 10 { 11 ....... 12 }
简单工厂模式的定义:
（1）单工厂模式 (Simple Factory Pattern)：定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。
（2）工厂模式中用于创建实例的方法通常是静态(static)方法，因此又被称为静态工厂方法(Static Factory Method)模式
要点：如果需要什么，只需要传入一个正确的参数，就可以获取所需要的对象，而无须知道其创建细节
★简单工厂模式的结构
3.简单工厂模式的结构与实现
简单工厂模式的结构
简单工厂模式包含以下3个角色：
Factory（工厂角色）
Product（抽象产品角色）
ConcreteProduct（具体产品角色）
简单工厂模式的实现
典型的抽象产品类代码：
1 abstract class Product 2 { 3 //所有产品类的公共业务方法 4 public void MethodSame() 5 { 6 //公共方法的实现 7 } 8 9 //声明抽象业务方法 10 public abstract void MethodDiff(); 11 }
典型的具体产品类代码：
1 class ConcreteProductA : Product 2 { 3 //实现业务方法 4 public override void MethodDiff() 5 { 6 //业务方法的实现 7 } 8 }
典型的工厂类代码：
class Factory { //静态工厂方法 public static Product GetProduct(string arg) { Product product = null; if (arg.Equals("A")) { product = new ConcreteProductA(); //初始化设置product } else if (arg.Equals("B")) { product = new ConcreteProductB(); //初始化设置product } return product; } }
典型的客户端代码：
1 class Program 2 { 3 static void Main(string[] args) 4 { 5 Product product; 6 product = Factory.GetProduct("A"); //通过工厂类创建产品对象 7 product.MethodSame(); 8 product.MethodDiff(); 9 } 10 }
4.简单工厂模式的应用实例
实例说明：
某软件公司要基于C#语言开发一套图表库，该图表库可以为应用系统提供多种不同外观的图表，例如柱状图(HistogramChart)、饼状图(PieChart)、折线图(LineChart)等。该软件公司图表库设计人员希望为应用系统开发人员提供一套灵活易用的图表库，通过设置不同的参数即可得到不同类型的图表，而且可以较为方便地对图表库进行扩展，以便能够在将来增加一些新类型的图表。
现使用简单工厂模式来设计该图表库。
实例代码
(1) Chart：抽象图表接口，充当抽象产品类
(2) HistogramChart：柱状图类，充当具体产品类
(3) PieChart：饼状图类，充当具体产品类
(4) LineChart：折线图类，充当具体产品类
(5) ChartFactory：图表工厂类，充当工厂类
(6) Program：客户端测试类
参考代码: (DesignPattermSimpleFactory)
引入配置文件：App.config:
using System.Configuration; …… //读取配置文件 string chartStr = ConfigurationManager.AppSettings["chartType"]; …… <?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="chartType" value="histogram"/> </appSettings> </configuration> …… Chart chart; chart = ChartFactory.GetChart(chartStr); //通过静态工厂方法创建产品 ……
5.创建与使用对象
C#语言创建对象的几种方式
使用new关键字直接创建对象
通过反射机制创建对象
通过克隆方法创建对象
通过工厂类创建对象
使用new关键字创建对象:
class Login { private UserDAO udao; public Login() { udao = new OracleUserDAO(); //创建对象 //上面的这行代码 若改为SQL ServerUserDAO必须修改源代码, //违背开闭原则 } public void Execute() { //其他代码 udao.FindUserById(); //使用对象 //其他代码 } }
实例分析
引入工厂类UserDAOFactory：
实例分析
引入工厂类UserDAOFactory
如果UserDAO的某个子类的构造函数发生改变或者需要添加或移除不同的子类，只要维护UserDAOFactory的代码，不会影响到Login
如果UserDAO的接口发生改变，例如添加、移除方法或改变方法名，只需要修改Login，不会给UserDAOFactory带来任何影响
将对象的创建与使用分离的其他好处
防止用来实例化一个类的数据和代码在多个类中到处都是，可以将有关创建的知识搬移到一个工厂类中，解决代码重复、创建蔓延的问题
构造函数的名字都与类名相同，从构造函数和参数列表中大家很难了解不同构造函数所构造的产品的差异 将对象的创建过程封装在工厂类中，可以提供一系列名字完全不同的工厂方法，每一个工厂方法对应一个构造函数，客户端可以以一种更加可读、易懂的方式来创建对象
何时不需要工厂？
无须为系统中的每一个类都配备一个工厂类
如果一个类很简单，而且不存在太多变化，其构造过程也很简单，此时就无须为其提供工厂类，直接在使用之前实例化即可
否则会导致工厂泛滥，增加系统的复杂度
例如：string类
何时不需要工厂？
无须为系统中的每一个类都配备一个工厂类
如果一个类很简单，而且不存在太多变化，其构造过程也很简单，此时就无须为其提供工厂类，直接在使用之前实例化即可
否则会导致工厂泛滥，增加系统的复杂度
例如：string类
6.简单工厂模式的简化
将抽象产品类和工厂类合并，将静态工厂方法移至抽象产品类中
7.简单工厂模式的优缺点与适用环境
模式优点：
实现了对象创建和使用的分离
客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可
通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性
模式缺点：
工厂类集中了所有产品的创建逻辑，职责过重，一旦不能正常工作，整个系统都要受到影响
增加系统中类的个数（引入了新的工厂类），增加了系统的复杂度和理解难度
系统扩展困难，一旦添加新产品不得不修改工厂逻辑
由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构，工厂类不能得到很好地扩展
模式适用环境：
工厂类负责创建的对象比较少，由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂
客户端只知道传入工厂类的参数，对于如何创建对象并不关心
到这里，我的文章已近尾声。感谢观看我的Blog， 后续还会有更精彩的内容，请加关注点赞，谢谢！