为什么要使用Spring

提高解耦，增强可扩展性

分析：        

当我们使用某个功能组件的时候，我们直接创建这个功能组件会出现什么问题？

  当这个功能组件很简单的时候，我们直接创建并使用它确实很简单明了，但是软件开发本来就是一个不断扩展的过程，本来很简单的功能组件随着时间的推移，它将会越来越复杂，这个时候当我们需要使用这个组件的时候，还适合直接去创建并使用它吗？答案当然是否定的。原因如下：

   当我们想使用一个组件的时候，首先解决它自己的依赖问题（这个功能组件可能会需要一些初始值我们需要设置，它的属性也可能是其他对象，我们需要手动创建这些对象并且赋值给它），再来解决自己的依赖问题（我们自己某个属性就是这个功能组件，我们将自己创建好的组件拿来自己用），在这个依赖关系还很简单的时候，我们似乎还能应付的过来，但是其依赖关系多且复杂，那么创建这个组件肯定是一个复杂的过程，如果我们硬编码在调用的地方，代码肯定又长又丑，并且肯定不止一处需要创建这个组件。如果只是又丑又长，只要好用也可以的，但是真的好用么？一般的情况是简单粗暴的方式解决的问题肯定扛不来多久就会出问题。当我们需要扩展这个功能组件的时候，例如增加n种依赖关系，改变了原来的n种依赖关系，改变某些属性的初始值，当你看着原来一大串又丑又长的代码，然后还需要进行新一轮的修改时候，是不是很崩溃？这个就是维护性不好，可扩展性差了。

  所以我们不应该自己去创建这个组件。我们不应该关注组件创建的细节。

解决办法：

这时候就出现了工厂模式和spring等来解决这些问题

   这些解决方案都是封装了组件创建的细节，我们只要去使用组件就行，不关心创建过程，这样我们就会轻松很多啦。

工厂模式分为几种：

简单工厂模式 ：

我们把创建功能组件的过程写在工厂类里边，当我们使用功能组件的时候，只要创建这个工厂并且传进去某个参数就能得到我们需要使用的功能组件，这样我们只需要和工厂耦合在一起，但不需要关注组件实现的细节。这样我们的问题解决了，我们要什么组件它就必须创建什么组件，这个工厂类就像一个全能的上帝，但是工厂那边貌似压力很大，当需要扩展一个组件的时候，就必须再在工厂里边写一套创建的逻辑，这样就违背了开闭原则（对扩展开放；对修改封闭），即可以允许扩展，但是不允许修改。要符合开闭原则即扩展但是不修改已有的代码，在java中可以用继承或实现类和接口就可以实现，当需要扩展的时候，直接生成一个新的子类或实现类就行，而不用修改已有的代码

工厂方法模式：

一个工厂不行，那就多个工厂。同一个工厂只生产同一类型的组件（组件实现了同一接口）。当需要增加一种类型的组件的时候，我们就增加一个新的工厂来生产它，而不必去修改原来的代码。这样虽然把生产组件的压力进行了分散，但是会出现很多的工厂。这里可以使用java 的继承或实现抽象类或接口。

抽象工厂：

一个工厂只生产一种类型的组件肯定满足不了日益增长的需求，那么就一个工厂生产出不同类型的组件，然后把每个不同的工厂的共同特征做一个抽象父类，以后子工厂继承便于扩展。

以上的工厂模式都是为了屏蔽组件创建细节，然我们与组件解耦，能有一个很好的扩展性。

现在有一个更方便的解决方案：spring

spring主要的2个特征

1.创建管理 bean（就是所有的java对象）

2.解决bean之间的依赖关系（谁调用谁的方法）

当我们需要使用一个组件的时候，spring早就已经在项目启动的时候把我们需要的组件创建好了，并且解决了组件自己的依赖关系，并且主动把组件推送给我们，所以我们直接使用就好，这样的好处是相对于工厂模式，我们不需要和任何东西耦合，又提高了解耦，增强了程序的可扩展行。

spring怎么知道你的代码的依赖关系？

直接想法是难道它会首先通读一遍你的代码，然后做一个结果分析，得出依赖关系？我们人确实需要这么做，但是机器不是啊，我们是通过一个spring的配置文件来配置bean之间的依赖关系，spring通过我们配置文件的各种标签来生成java代码在底层执行实现创建管理bean，并解决依赖关系。还有基于注解形式的，机制应该差不多。

所以使用spring是一个不错的选择。