Spring的IOC理解+工厂模式介绍

概念：依赖注入。

原理：将对象的控制权交给工厂，控制权就是对象的创建权，调用者需要用到某个对象时，只需要通过工厂获取即可。

知识点：

（1）反射技术。

SpringIOC创建对象时，需要利用到反射技术，用到两个主要的方法。

第一个：Class.forName()；获取到创建对象的类。

第二个：类的newInstance()；获取对象。

这样对象就被创建出来了。

（2）工厂模式。

SpringIOC创建对象是使用反射的技术，创建对象的过程是放在工厂里面的，此时我们不需要知道对象是如何创建的，只需要清楚我们需要什么对象就行，这样做有一个好处就是，降低了调用者和被调用者直接的耦合。

工厂模式细分有三种：简单工厂模式、工厂方法模式、抽象工厂模式。我发现他们三者好像是有递进关系，后面的一种总是在解决前一种的问题，所以，按照顺序，后面的模式对前面的模式算是一种优化。

简单工厂模式：就是将多个对象的创建过程放到同一个工厂里面，调用者创建对象时，从工厂获取就行，这样做的很大一个优点就是，将对象的创建过程封装起来了，比如：某个对象创建比较复杂，需要很多条件，使用工厂模式封装后，也变得非常简单了，这里的简单指的是我们不需要每次都重复的获取这些条件，工厂模式封装使得这些条件可以复用。但是这样做的缺点也很明显，就是多个对象放在一个工厂里面，这个工厂类会变成超级类，负担很大，再者，如果需要扩展时，需要修改工厂类，这违背了程序设计的开闭原则，同时，因为工厂类的有多个对象的创建过程，那么当这些类有变动时，都会去更改这个工厂类，使得引起这个类变动的原因很多，那么就违背了设计原则中的单一职责原则。

工厂方法模式：为了解决超级类、开闭原则和单一职责原则，对简单工厂的优化，把每个类都分离出来，每一个类的创建对应的一个工厂，这样做的好处就是：如果需要扩展类时，直接添加工厂类就行了，符合程序设计的开闭原则；每个工厂类的被更改的理由也只有一个，那就是该工厂创建的类需要更改，这也就符合了程序设计中的单一职责原则。这里有一个疑问就是：每一个类都创建一个工厂和调用者直接创建类没什么区别，并没有明显的降低类与类之间的耦合度，但是像前面描述的一样，如果一个类的创建需要很多条件的铺垫，那么将这个过程封装在工厂里面，也是明显降低了类之间的耦合度了。因此设计模式的使用是需要按照场景来进行选择的，如果这个类比较简单，直接创建，或者使用简单工厂模式即可，复杂一点的类再使用工厂方法模式。

抽象工厂模式：抽象，我的理解就是提取共性。将一些具有共性的类抽象出一个接口，然后这些类都去实现这个接口，此时，这些类就需要实现该接口的所有方法，这样做的好处就是：程序在拿到工厂的返回值时，可以用接口类型定义变量，使得这个变量在作为某些方法的参数时更加灵活，具体的意思就是，方法的参数是接口类型的变量，那么传入的实参可以是实现该接口的任何实现类，使得方法的参数不唯一，变成了一对多的关系，在一定程度上弱化了类之间的耦合性，相反，如果使用具体的类作为参数，那么参数的类型就被限定死，就没有那么灵活了。还有一个好处：因为都使用了该接口类型定义变量，那么后续代码在使用这个变量时，都是按照接口类型类使用的，根本不关注是某一个工厂创建出来的，如果需要替换成另外一个实现类时，只需要变更获取对象那一行代码即可，后续代码都是不需要更改的，因为接口里面的方法名都是一样的。抽象工厂模式很好的符合了程序设计的开闭原则和依赖倒置原则，缺点就是如果接口新增方法后，会影响到所有的实现类，因此，抽象工厂模式适合横向的扩展，也就是添加实现类，而不是适合纵向的扩展，也就是在接口中添加方法。

总结出一句关于设计模式的话：没有最好的设计模式，只有最合适的设计模式。