目录
代码讲解
产品功能接口：
/**
* 定义接口，抽象出产品都具有的功能
*/
interface Produce {
void method();
}工厂类：
/**
* 我们下面的代码，模拟API
*/
public class SimpleFactory {
//根据传进来的参数，返回对应的对象
public static Produce factory(String produce) throws Exception {
Produce produce1;
switch (produce) {
case "Piano":
produce1 = new Piano();
break;
case "Motorcycle":
produce1 = new Motorcycle();
break;
default:
produce1 = null;
}
if (produce1 == null) {
throw new RuntimeException("没有参数对应的产品");
} else {
return produce1;
}
}
}具体实现类：
/**
* 钢琴类
*/
class Piano implements Produce {
@Override
public void method() {
System.out.println("制造一架钢琴！");
}
}
--------------------------------------------------------------
/**
* 摩托车类
*/
class Motorcycle implements Produce {
@Override
public void method() {
System.out.println("制造一台摩托车！");
}
}测试：
/**
* 下的代码，模拟客户端，在客户端调用上面的API
*/
@Test
public void test() throws Exception {
// 客户端需要制造一台钢琴
Produce produce = SimpleFactory.factory("Piano");
produce.method();
// 客户端制造一台摩托车
Produce produce1 = SimpleFactory.factory("Motorcycle");
produce1.method();
}UML图解简单工厂
优点
- 隐藏具体实现
- 解耦
- 简单
分析优点：
我们可以想象我们是一个API 的 设计者 ，我们设计出一个框架，对外提供一些产品； 如何设计这个框架，是一个技术活，要尽量做到，对客户端 隐藏具体实现，同时满足简单、解耦的特点；
我们讲的简单工厂模式，是可以满足我们的要求的，具体怎么满足的，请看下面的分析；
像 Produce1、Produce2，这样的具体产品实现类，是API的设计者实现的，客户端的程序员是不用知道具体的实现的，他们只需要知道怎么用，就好了，这也就对客户端程序员 隐藏了具体实现；
对于一些非常复杂，创建对象很麻烦的类，更能体现出 简单 的优点，因为怎么 new实例，都是在 API 设计者在 工厂类 里面自己帮客户端程序员new好了，客户端程序员只要直接使用这个对象就好了，不需要关心怎么new出来的；
解耦 是如何实现的呢？其实很简单，因为客户端没有new xxx 这样的硬编码啊，后期就是API的设计者，把框架的代码，都改了，各种类（除了工厂类）的名字都换了，只要工厂类的名字、方法名字没变，客户端的代码，一行都不要动；这是多么的美滋滋；
缺点:
- 扩展麻烦，需要改动现有的代码
- 孤注一掷
其实仔细看代码，就能发现缺点，假如框架新增加了一些产品类，那么我们的工厂类的代码，就需要改动，这是爽了客户端程序员，麻烦了API设计者 ；
所有的逻辑都放在一个工厂里面，一旦这个类出现什么问题，那么就全GG ；
改进：
要想改变这种缺点，就需要使用 工厂方法模式 了 ；