我准备战斗到最后，不是因为我勇敢，是我想见证一切。 --双雪涛《猎人》
[TOC]
Thinking
- 一个技术，为什么要用它，解决了那些问题？
- 如果不用会怎么样，有没有其它的解决方法？
- 对比其它的解决方案，为什么最终选择了这种，都有何利弊？
- 你觉得项目中还有那些地方可以用到，如果用了会带来那些问题？
- 这些问题你又如何去解决的呢？
本文主要基于 Spring 5.2.7.BUILD-SNAPSHOT
春天这么春天，冬天还会远吗？Fuker！！！
我觉得在学习Spring源码后，学习到了非常优雅的编码习惯，在实现一个功能时，假如它需要完成各种各样的不同的环境的任务，那么这些繁杂的操作就要交由那些个具体的实现去完成了，顶层的抽象也可以起到一个聚合作用，起到了同意的管理，这样一来就实现了职能划分清晰，条例清晰的优秀代码哦！
在Spring资源加载中就有非常明显的体现了
- 职能划分清楚，具体的资源加载交由具体的实现来完成（ex：xml、url、jar 等等。。）
- 同意的抽象，统一的资源定义和资源加载策略。资源加载后要返回统一的抽象给客户端，客户端要对资源进行怎样的处理，应该由抽象资源接口来界定。
上述文章提及到了，Spring的加载流程，其实就源码分析，就可以分为两个阶段
- 资源的解析，工厂的装配
- 使用工厂提取具体的bean信息
现在先尝试完成第一步的解析，资源的解析，工厂的装配
1、资源加载
Resource resource = new ClassPathResource("applicationContext.xml");
这里直接使用的
ClassPathResource。
现在看看Spring的资源加载的整体体系。
image-20200612202302709
可以看到Spring对于资源的加载多了顶层的抽象。
来看看
org.springframework.core.io.Resource定义呗
image-20200612202503404
- 该接口是对资源的描述，它是可以实现文件资源或者classPath下的资源。
- 并且一个输入流是可以打开所有的资源的，但是网络上的资源就无能为力了，所以需要特定的实现去做自己擅长的事，才出现了这样的层次关系，和各种不同的实现了。
Resource定义了很多公共的方法。
1.1、ClassPathResource的具体实现
image-20200612204326028
可根据给定的
ClassLoader去加载类路径资源。
1.1.1、构造函数
image-20200612214455743
以上两种情况是针对有无类加载器的情况进行具体的初始化的
对路径的要求就可以看到Spring考虑的非常周全了，因为这种加载不定因素的东西，存在各种各样的情况，后续就可以看到Spring做了大量的工作将这些脏活累活全部封装到底层了。
- 会考虑到该路径是否合法啊，路径的字符串是不是真正的指向的一个路径资源等等。。。
image-20200612210016883
该构造器针对class类了yo。
可以看出，Spring提供了两种初始化的方式
- 更加通用的一种方式，使用类加载器
- 使用class类的类加载器去初始化的
来看看Spring对路径加载做了什么脏活累活哦，具体分析查看一下源码吧 org.springframework.util.StringUtils#cleanPath
发现一个彩蛋，_
image-20200612220741669
1.2、类加载器获取
来看看在构造方法中，如何获取ClassLoader的
image-20200612221144030
Spring想尽了一切办法，去让整个程序运行起来，真的操碎了心哦！
image-20200612221244616
这里就org.springframework.core.io.ClassPathResource整个初始化就完成了
加载完之后再就是需要一个根据资源来加载Bean的工厂了。
2、Spring工程创建流程
image-20200612222418438
这是Spring推荐的一种创建方式。
看看Spring对BeanFactory的整体抽象
image-20200612223217632
大体是可以分为两大类的
在构造函数中可以看到一个比较特别的地方
image-20200612223338516
这里手动的忽略了三个接口
本文仅供笔者本人学习，一起进步！
加油！
网友评论