简单工厂模式到底违反开闭原则吗？
很多人都说简单工厂模式违反开闭原则，因为，如果新添加一个产品类，就需要修改工厂类中的代码。

我觉得如果简单工厂模式违反开闭原则，那么工厂方法模式也违反了开闭原则。

我的分析是这样的：

（这是我的一个分析的文章，http://blog.csdn.net/tayanxunhua/article/details/10297013，大家如果觉得我是打广告的，那么可以不看，我在这里再解释一下）

一个TV产品类，HaierTV和HisenseTV实现了这个类；
一个工厂类，还有一个测试类。

工厂类的实现：
    public static TV getTV(String name) {  
      if (name.equals("Haier")) {  
          return new HaierTV();  
      } else if (name.equals("Hisense")) {  
          return new HisenseTV();  
      } else {  
          return null;  
      }  
    }  
这样肯定是违反开闭原则的，原因就不说了。
但是如果我这样修改呢？
    public static TV getTV(String name) throws InstantiationException, IllegalAccessException, ClassNotFoundException {  
        TV tv = (TV) Class.forName("com.tyxh.pattern.sample." + name).newInstance();  
        return tv;  
    }  

修改了之后，是否还违反开闭原则呢？

当然了，可能会有这种情况，现在有一个TV的产品类，如果我想再添加一个Fruit产品类，那么就需要修改工厂类的代码了吧。

我觉得简单工厂模式确实违反了开闭原则，但是工厂方法模式是否又违反了开闭原则呢？

我添加一个新的产品类的时候，不是也需要修改测试类的代码么？
------解决方案--------------------
工厂方法模式并未能完全避免违反开闭原则啊~

难道谁跟你说它没有违反开闭原则么？ - -

工厂方法只是实现了对产品角色创建的封装，避免了工厂角色内部违反开闭原则~(简单工厂模式并未做到这一点~)

引用一句话来说明这个问题：“在工厂方法模式中，要么将判断逻辑留在抽
象工厂角色中，要么在客户程序中将具体工厂角色写死。而且产品
对象创建条件的改变必然会引起工厂角色的修改。”
------解决方案--------------------
设计模式并没有完美的，能看到它的闪亮点就行。
工厂方法本身是符合开闭原则的，但要说到客户端，客户总得自己决定创建什么样的对象吧，这个在服务端没法帮客户确定，所以客户端代码需要改是不可避免的。客户端要么自己创建具体的工厂类，要么通过类型参数，让服务端返回合适的对象。
------解决方案--------------------