学习设计模式之详解工厂模式

1. 写在前面

这篇文章是我酝酿了近一个月的时间写出来的，我想在第一个模式上就写出工厂模式，却一直推迟到现在。

工厂模式，看似很容易，很常见，但是学习设计模式两年，我至今仍未能真正地充分理解工厂模式的意图。工厂模式好在哪，他究竟解决了什么问题，工厂还是不工厂，困扰了我整整两年。

从无模式，到为模式而模式，在到今天的重温设计模式。我已经记不清大多数模式的样式了，只记得一系列的设计原则，然后去思考模式的综合。但是工厂模式，至今我仍然难以理解。

写出这篇文章，更多的目的是为了抛砖引玉，希望大家能够多多指教。（初学者选学）

2. 从简单工厂谈起

简单工厂是工厂模式的简化，很多人说他并不是模式，我却不这样认为。相反，我认为简单工厂在某种程度，某些场合上，比起略重量级的工厂模式更为合适。

简单工厂就像一些外包公司，他们没有固定的项目方向，只要给他们一个项目，他们就会去做，而不管这个项目的类型。

让我们先来看看简单工厂的UML图：

3. 简单工厂示例

就写出我们上面UML图的例子了：

class Program
{
    static void Main(string[] args)
    {
        Product product = Factory.CreatePruduct(Type.ProductA);
    }
}

enum Type
{ 
    ProductA,
    ProductB
}

class Factory
{
    public static Product CreatePruduct(Type t)
    {
        switch (t)
        { 
            case Type.ProductA:
                return new ProductA();
                break;
            case Type.ProductB:
                return new ProductB();
                break;
        }
    }
}
abstract class Product
{ 

}

class ProductA : Product
{ 
    
}

class ProductB:Product
{ 

}

让我们来看下，简单工厂的特点：

他把对象的创建都封装到了一个简单工厂类里，然后让客户端和工厂类发生耦合，而脱离了和具体对象的耦合关系。

优点和缺点暂且不说，这个我们在下文中对比着去看。

4. 进入工厂模式

工厂模式与简单工厂的最大特点就是单一了简单工厂的职责，由外包公司成功转型为行业性软件公司。每个工厂只生产一类产品，这样的优点是取出了简单工厂中丑陋的switch-case或者是if-else。

看下结构图：

我觉得这个图不能很好地表达出工厂方法的意思。让我们先继续向下看：

工厂模式定义一个用户创建对象的接口，让子类去决定实例化哪一个类。