设计模式之——工厂方法（factory）

1 简单工厂（Static Factory）

简单工厂方法，又称静态工厂方法，并不是GOF的23种模式之一，是比工厂方法更简单的一种设计模式。

简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例，说简单一点就是把一些if else封装在一个函数里面。 你不需要管一个对象是如何new出来的，只需要调用方法拿到这个对象。其类图如下



PS：这里有一点要说明的是，简单工厂模式里面出现具体的产品都有共同的基类，要不然CreateProduct方法就不知道返回什么类型，在有共同基类的时候返回的是基类Product指针。

优点：

好处就是可以服用创建对象这部分代码，增加代码可读性，也就是一般封装的优点。如果你发现一个对象new的过程很复杂，但是又有很多地方要用这个对象，可以使用简单工厂模式。通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。

缺点：

由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。

当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；

　　这些缺点在工厂方法模式中得到了一定的克服。

2 工厂方法（Factory Method）

工厂方法模式的意义是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。其类图如下



这样如果要增加一个新的具体产品，我就可以只修改ConcreteFactory，而不需要Factory，或者再创建以下具体工厂类来创建新产品（这样就符合开放封闭原则（OCP）原则）；另外因为它将创建具体产品的工作放到了具体工厂类中，那么就可以用多态的方法实现统一的接口，但不同的创建结果，而这一切对于使用者来说是透明的。其实工厂方法的类图关系可以更简单，即product里面提供一个抽象方法接口，createproduct， 然后由各自的子类去实现这个方法。从类图关系的这个角度来看很像模板方法，只是模板方法抽象的是一些具体步骤，而这里抽象的是创建。

3 抽象工厂（Abstract Factory）

可以看出，Factory 模式对于对象的创建给予开发人员提供了很好的实现策略，但是不管是简单工厂还是工厂方法模式仅仅局限于一类类（就是说 Product 是一类，有一个共同的基类，因为CreateProduct肯定要返回一个类型的，如果他们的具体产品没有相同的基类就不好办了，有相同的基类就可以返回基类的指针） ，如果我们要为不同类的类提供一个对象创建的接口，那就要用 AbstractFactory了。