举个例子
假设需要我们写一个简单的计算器，能实现加减乘除运算，仅要求输入两个数，选择运算符，计算出结果就行了。
使用简单工厂模式的设计如下：
工厂类提供了一个getBean函数，该函数会根据客户端输入的key来判断究竟new运算类的哪一个子类对象。
简单工厂模式的弊端：
当需要增加计算器的功能时，比如要增加一个开根号的功能，那么首先需要创建一个开根号子类，继承运算类，并实现operation函数；
除此之外，还需要修改工厂类，在getBean函数中增加对开根号的判断。
也就是说，简单工厂模式在增加功能时，需要修改工厂中的getBean函数，破坏了“封闭修改”的原则。而工厂模式能解决这个问题。
用工厂模式来实现：
由于在简单工厂模式中，增加功能时需要修改工厂类的代码，这时候我们应该敏锐地察觉到：我们破坏了“封闭修改”地原则，说明我们修改的那个类是面向实现编程，因此我们要给修改的工厂类抽象出一个父类/接口，从而达到面向接口编程，这就是“依赖倒转”的思想。
当我们使用了工厂模式之后，如果需要增加开根号运算的话，在增加开根号运算类的基础上，我们还需要增加开根号工厂类，让它去继承工厂父类，覆盖里面的getBean函数，在该函数中只创建开根号类的对象。
此时我们发现，再怎么增加功能，工厂类和运算类都没有作任何修改，都只是增加新类而已。这就满足了“开放扩展，封闭修改”的原则。
工厂模式的弊端：
工厂模式使得低层类实现了“开放-封闭”的原则，但在客户端，究竟使用哪个工厂子类获取运算类的对象，这件事情就要在客户程序中判断了。也就是把简单工厂模式中的判断，转移到了客户端。
mian(){
Factory factory;
switch (key){
case " ":
factory = new 加法Factory();
break;
case "-":
factory = new 减法Factory();
break;
case "*":
factory = new 乘法Factory();
break;
case "/":
factory = new 除法Factory();
break;
}
运算类 运算对象 = new factory.getBean();
}
工厂模式和简单工厂模式的比较：
简单工厂模式把创建哪个运算类的对象放在工厂类中实现，也就是放在低层模块中实现；从而客户端在需要创建对象时仅仅需要给工厂传入一个key就能获取想要的对象。但当运算体系需要扩展的时候，就需要在工厂中增加新对象的判断，从而破坏了“封闭修改”的原则。
工厂模式由于抽象出了一个工厂父类，并且每一运算子类都有一个专门创建该子类对象的工厂子类，因此在增加运算子类的时候，工厂类不需要修改任何代码，只需要增加一个工厂子类即可。但客户端就需要给判断究竟给工厂父类创建哪个工厂子类对象。
