之前在学校里没有学过spring相关的知识，这一次暑假来实习的时候被补了课，写一下自己的理解，以下仅为个人观点。
在此之前我从来没有接触过Spring，在学习Spring之前首先应该知道它是干什么的。以我的理解来说，Spring所做的最重要的一件事情就是解耦，在解耦之后能带来的就是更灵活的操作，使得程序有了更好的可扩展性。
IoC
Spring的核心技术有两个，其中一个是IoC，IoC的思想是将原本对象的控制权统一交给容器。原本程序在调用的时候需要new一个新的对象，这样两者之间就产生了依赖。而IoC通过容器让程序不能直接new一个对象，这一点来说有一些像之前学校里老师讲到的单例模式，程序不能主动的去创建一个对象，而是通过向别的东西申请来去获得这个对象。
这种情况就好比之前我是去食堂打饭，并自己将它提回宿舍，而现在我只需要点个外卖，自然有人会把东西送到楼下。
相较于之前主动的去创建，IoC让程序显得更为被动，但是也更加简单，因为对于程序来说它不需要直接面对对象，自己去选取合适的对象，而只需要描述自己的要求就可以，从而减少了它的工作。而这样将两者解耦使得开发更加灵活，减少了出现“牵一发而动全身”的情况的出现。
在程序描述了自己的需求之后，容器要根据提交的请求去创建一个符合要求的对象，并将这个对象交给请求者，IoC的思想实现使得程序之间显得更加简单明了，它们只需要做好自己的“分内事”并告知自己所需要的东西就可以了，不属于它们的东西由Spring来提供和统一管理。
在具体实现的过程中，只需要加上不同的注解来告诉spring自己的需求就可以了，比如告诉spring某个类是可以被配置成Bean的，或者我需要某种依赖，提交了自己的申请之后剩下的工作由Spring来做，由它来决定哪些被装配成Bean，哪些依赖将被注入，何时注入。
AOP
Spring的另一个核心就是AOP，在了解AOP之前需要先了解一下代理模式。
- 代理模式
如同字面意思，代理模式就是对一个程序进行代理，其他对象不再直接的与被代理的类进行交互，而是通过代理对象来沟通。在代理模式中，代理人除了通知被代理的对象具体实行某些操作外，还可以进行一些别的操作。
代理模式又分为静态代理与动态代理，其中静态代理是规定好的，即每一个代理类已经知道了自己将要代理谁，而动态代理则不知道自己具体是负责谁的，只有当运行起来之后它才知道自己应该代理的是谁。
通过Proxy和InvocationHandler将代理类和被代理的类关联起来，并根据调用的方法不同来进行不同的操作，除了能够真正的执行以外还可以增加一些扩展的功能。这样根据需求的不同来创建不同的类，而不是单纯一对一的创建，相对更为灵活。
AOP就是基于灵活的动态代理模式来实现的，但AOP并不等于动态代理，它仅仅是实现了动态代理模式的一部分功能。
在动态代理模式中除了根据方法调用不同加上不同的“装饰”或是根据不同的异常做出了不同的反应之外，这个代理类还真正的让这个方法得到了执行，也就是真正执行这个工作的类要得到代理对象的通知之后才开始进行操作。
但是AOP则是将动态代理中对执行以及执行结果的修饰的部分提取了出来，程序并没有通过他去执行，完成该功能的模块依旧是主体，什么时候执行由它自己做决定。AOP只是负责在规定好的时间和地点对它进行修饰，因此完成功能的程序依旧是独立的，AOP起到了辅助的功能而与核心功能无关。
AOP想做到的一点就是将一些与程序功能实现无关的公共事物提出，整合在一起，这样在其他程序实现的过程中不用每次都去在代码中实现这些功能，而只需要告知Spring自己要在什么时候执行这些公共方法就可以了。在程序执行的过程中，spring就会根据事先规定在切点位置执行通知。
而AOP里几种通知的类型就相当于不同的修饰类型，通过注解来定义不同的切面，让这些与功能实现无关的公共操作在合适的时间和位置得以进行。
IoC与AOP
作为spring的两个技术核心，IoC的思想让程序简单化，但是仅靠IoC程序还不够“专注”，于是引入了AOP让一些公共操作得到执行。对于这些公共操作，程序不需要提前告知自己的请求，因为它们已经被规定好了。
IoC保证了每一个模块在纵向上的简单，而AOP则保证了模块在横向上的专注，两者结合之下能够使得每一个功能模块变得更加短小精悍，它们只需要专注于自己的功能的实现，必要的时候提出申请就可以了。
得益于这两个核心的技术，spring才能降低程序的耦合，让不同模块之间的逻辑更加清晰，更加灵活，可扩展性更强。
