浅说工厂相关的几个模式

常听与工厂相关的几个模式，简单工厂，工厂方法，抽象工厂，他们的区别，关系，使用场景是什么？

1.假设有一个父类，子类1，子类2，子类3(或者有一段代码，if else分支中逻辑比较复杂，分支可以抽成一个单独的类，那么抽成父类，子类1，子类2.。。)
这三个子类可以根据某个条件的不同决定使用哪个类，这时候就可以用简单工厂，将对象的创建交由工厂去做，如：

public class XXXFactory{public static 父类 getXXX（param）{if（）{return new 子类1；}else if（）{return new 子类2；}...}}

这个时候我们只需要指定一个参数，就可以由工厂创建一个自己需要的类的对象，缺陷是什么呢？如果子类增加了，就需要修改工厂方法的分支部分代码。按照开放-封闭的原则，这不是好的方法。

2.有问题，怎么改进呢？就是工厂方法模式。
问题在于getXXX方法，那就将其变成可扩展。将每一个if else 变成一个类，并未这些类抽出一个接口IFactory。那么：

public Factory1 implements IFactory{public 父类 getXXX（）{return new 子类1；}}

同理工厂2对应子类2，这样就解决了增加子类无需修改代码，只需要增加一个工厂类就可以了。有缺陷么？有。通常情况可能还需要父类2，父类3，也是可能的。总不能再搞几个同样的IFactory2，IFactory3，这就弱爆了。

3.改进方法，将弱爆了的IFactory1，IFactory2，IFactory3合并到一个接口IFactory中，只是包含了3个方法，分别解决父类1，父类2，父类2的方法。也即抽象工厂模式。不过此模式未做深入了解，不言好还是不好。

4.此时若增加一个子类4（注意不是父类了哈），带来的后果是什么，就是工厂自上至下都要增加一个方法，这如何解决？

5.回归简单工厂，去掉所有的IFactory及其子类，用一个简单工厂类+多个创建方法+每个方法内switch来取代。这不又回去了么？到底要闹哪样？所以没有绝对的好与坏，只能根据业务场景决定自己的取舍。

6.再高级一点，就是spring的DI，需要哪些类放在配置文件中指定，增加新类是只是换一个字符串，然后利用反射根据类名生成新的类。