小A：“什么是简单工厂模式？”
大B：“简单工厂模式又叫静态工厂模式，顾名思义，它是用来实例化目标类的静态类。”
小A：“简单工厂模式有什么优点？”
大B：“现在我就主要通过一个简单的实例说明简单工厂及其优点。”
小A：“嗯。好。”
大B：“就如刚才我讲过的，有个国家的运动员协会。”
下面给出各个类的程序。
Code：[Copy to clipboard]
运动员。java
public interface 运动员{
public void 跑（）；
public void 跳（）；
}
足球运动员。java
public class 足球运动员implements 运动员{
public void 跑（）{
//跑啊跑
}
public void 跳（）{
//跳啊跳
}
}
篮球运动员。java
public class 篮球运动员implements 运动员{
public void 跑（）{
//do nothing
}
public void 跳（）{
//do nothing
}
}
体育协会。java
public class 体育协会{
public static 运动员 注册足球运动员（）{
return new 足球运动员（）；
}
public static 运动员 注册篮球运动员（）{
return new 篮球运动员（）；
}
}
俱乐部。java
public class 俱乐部{
private 运动员 守门员；
private 运动员 后卫；
private 运动员 前锋；
public void test（）{
this 前锋=体育协会，注册足球运动员（）；
this 后卫=体育协会，注册足球运动员（）；
this 守门员=体育协会，注册足球运动员（）；
守门员，跑（）；
后卫，跳（）；
}
}
大B：“这就是简单工厂模式的一个简单实例，你应该想象不用接口不用工厂而把具体类暴露给客户端的那种混乱情形吧？就好像没了体育总局，各个俱乐部在市场上自己胡乱的寻找仔细需要的运动员。简单工厂就解决了这种混乱。我们用OCP看看简单工厂，会发现如果要对系统进行扩展的话治需要增加实现产品接口的产品类（上例表现为‘足球运动员’，‘篮球运动员’类，比如要增加个‘乒乓球运动员’类），而无需对原有的产品类进行修改。”
小A：“这咋一看好像满足OCP。”
大B：“但是实际上还是需要修改代码的――对，就是修改工厂类。上例中如果增加‘乒乓球运动员’产品类，就必须相应的修改‘体育协会’工厂类，增加个‘注册乒乓球运动员’方法。所以可以看出，简单工厂模式是不满足OCP的。”
小A：“那工厂方法模式哩？”
大B：“我们刚刚讲了简单工厂模式，下面继续谈谈工厂方法模式。刚才点明了简单工厂模式最大的缺点――不完全满足OCP。为了解决这一缺点，设计师们提出了工厂方法模式。工厂方法模式和简单工厂模式最大的不同在于，简单工厂模式只有一个（对于一个项目或者一个独立模块而言）工厂类，而工厂方法模式有一组实现了相同接口的工厂类。下面我们通过修改刚才的实例来介绍工厂方法模式。我们在不改变产品类（‘足球运动员’类和‘篮球运动员’类）的情况下，修改下工厂类的结构。”
相关代码如下：
Code：[Copy to clipboard]
运动员。java
public interface 运动员{
public void 跑（）；
public void 跳（）；
}
足球运动员。java
public class 足球运动员implements 运动员{
public void 跑（）{
//跑啊跑
}
public void 跳（）{
//跳啊跳
}
}
篮球运动员。java
public class 篮球运动员implements 运动员{
public void 跑（）{
//do nothing
}
public void 跳（）{
//do nothing
}
}
体育协会。java
public interface 体育协会{
public 运动员 注册（）；
}
足球协会。java
public class 足球协会implements 体育协会{
public 运动员 注册（）{
return new 足球运动员（）；
}
}
篮球协会。java
public class 篮球协会implements 体育协会{
public 运动员 注册（）{
return new 篮球运动员（）；
}
}
俱乐部。java
public class 俱乐部{
private 运动员 守门员；
private 运动员 后卫；
private 运动员 前锋；
public void test（）{
体育协会 中国足协=new 足球协会（）；
this。前锋=中国足协，注册（）；
this。后卫=中国足协，注册（）；
守门员，跑（）；
后卫，跳（）；
}
}
大B：“很明显可以看到，‘体育协会’工厂类变成了‘体育协会’接口，而实现此接口的分别是‘足球协会’‘篮球协会’等等具体的工厂类。”
小A：“这样做有什么好处呢？”
大B：“很明显，这样做就完全OCP了。如果需要再加入（或扩展）产品类（比如加多个‘乒乓球运动员’）的话就不再需要修改工厂类了，而只需相应的再添加一个实现了工厂接口（‘体育协会’接口）的具体工厂类。”
小A：“工厂方法模式是为了克服简单工厂模式的缺点（主要是为了满足OCP）而设计出来的。但是，工厂方法模式就一定比简单工厂模式好呢？”
大B：“不一定。1、结构复杂度。从这个角度比较，显然简单工厂模式要占优。简单工厂模式只需一个工厂类，而工厂方法模式的工厂类随着产品类个数增加而增加，这无疑会使类的个数越来越多，从而增加了结构的复杂程度。2、代码复杂度。代码复杂度和结构复杂度是一对矛盾，既然简单工厂模式在结构方面相对简洁，那么它在代码方面肯定是比工厂方法模式复杂的了。简单工厂模式的工厂类随着产品类的增加需要增加很多方法（或代码），而工厂方法模式每个具体工厂类只完成单一任务，代码简洁。3、客户端编程难度。工厂方法模式虽然在工厂类结构中引入了接口从而满足了OCP，但是在客户端编码中需要对工厂类进行实例化。而简单工厂模式的工厂类是个静态类，在客户端无需实例化，这无疑是个吸引人的优点。4、管理上的难度。这是个关键的问题。我们先谈扩展。众所周知，工厂方法模式完全满足OCP，即它有非常良好的扩展性。”
小A：“那是否就说明了简单工厂模式就没有扩展性呢？”
大B：“不是的。简单工厂模式同样具备良好的扩展性――扩展的时候仅需要修改少量的代码（修改工厂类的代码）就可以满足扩展性的要求了。尽管这没有完全满足OCP，但不需要太拘泥于设计理论，要知道，sun提供的java官方工具包中也有好多没有满足OCP的例子啊（java。util。Calendar这个抽象类就不满足OCP）。然后我们从维护性的角度分析下。假如某个具体产品类需要进行一定的修改，很可能需要修改对应的工厂类。当同时需要修改多个产品类的时候，对工厂类的修改会变得相当麻烦（对号入座已经是个问题了）。反而简单工厂没有这些麻烦，当多个产品类需要修改是，简单工厂模式仍然仅仅需要修改唯一的工厂类。”