工厂方法模式

简单工厂模式

设置专门的一个类来负责实例化其他的实例，这就是工厂。使用简单工厂模式，客户端只需要与工厂（factory类）与抽象类接触，降低了耦合度。简单工厂模式可以分为三部分：抽象类，具体实现类与factory。其中抽象类是factory的一个成员变量，factory根据一定的条件实例化其子类。
简单工厂模式最大的优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类。对于客户端来说，去除了与具体产品的依赖，但这也导致简单工厂模式违反了开放-封闭原则。

对于一个简单的四则运算的程序，使用简单工厂模式的UML类图如下

工厂方法模式

定义了一个用于创建对象的接口让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类。

使用工厂方法模式来实现四则运算的UML类图

使用工厂方法模式，在增加一个新的计算方法时，需要增加一个性的运算类的子类与工厂类的子类，而不需要去修改工厂类原本的代码，这符合开放-封闭原则，是值得提倡的。但这也导致了将简单工厂的内部逻辑判断转移到了客户端来进行，本来应该修改工厂类，现在变成修改客户端的代码。

在实际开发时，如果我们需要在客户端使用工厂实例化多个对象，使用简单工厂模式时，代码为

Product product_1 = new Creator("条件");
Product product_2 = new Creator("条件");
Product product_3 = new Creator("条件");

使用工厂方法模式实例化多个对象的代码为

Creator creator = new ConcreateCreator();
Product ConcreateProduct_1 = creator.FactoryMethod();
Product ConcreateProduct_2 = creator.FactoryMethod();
Product ConcreateProduct_3 = creator.FactoryMethod();

当需求改变要求我们修改代码时，使用工厂模式只需要修改实例化的工厂类就可以，而简单工厂模式内部有3条重复的语句，需要我们修改3处。

简单工厂模式与工厂方法模式都集中封装了对象的创建过程，但工厂方法模式降低了客户程序与产品对象的耦合，这也导致每增加一个产品，就需要增加一个生产工厂的类，增加了额外的开发量。

还有一种更好的方法是采用反射机制。