场景：简单工厂时候，我设计了一个场景，有三种剑去打怪，这时候，需求变化了，我三种剑变成了，匕首、剑以及木棒，想要用工厂方法来实现，怎么弄？
1.上文讲过简单工厂模式，它的最大优点在于工厂类内有创建类型的判断逻辑，客户端只需要通过动态的选择想要创建的类型，就可以交给工厂类来创建，去除了客户与具体产品之间的依赖。
缺点在于，当新建一个类型的时候，需要修正工厂类中的判断逻辑，添加一个case，此时就违背了开放-封闭原则。
2.工厂方法模式的引入：定义一个用于创建对象的接口，让子类觉得实例化哪一个类，工厂方法模式使得一个类的实例化延迟到了它的子类。
客户端再使用工厂方法模式的时候，需要决定实例化哪一种工厂，选择判断的问题依然存在，也就是说工厂方法模式是对简单工厂的改进，把判断逻辑移动到了客户端。当加入新功能时候，原来是要修正工厂类，现在修改客户端就行了。
领悟：例如在进行编写一个计算器的时候。
- ①如果把所有的判断逻辑和类的创建放在一个类中，那么出现的问题是，新增加一个功能，其他的功能也会收到影响。所以引进了简单工厂模式，使得耦合性降低了。
- ②简单工厂在添加新功能的时候，需要改工厂类，同样违背开放-封闭原则，对更改是关闭的，对扩展是开放的。
- ③针对简单工厂又出现了工厂方法，这时候将工厂类进一步抽象为多个工厂类。这时候我添加一个新功能，就需要添加一个新的工厂类和一个具体的功能类。工作量也变大了。