Spring精髓（二）-Spring资源与工厂创建流程分析

我准备战斗到最后，不是因为我勇敢，是我想见证一切。 --双雪涛《猎人》

[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做了大量的工作将这些脏活累活全部封装到底层了。

会考虑到该路径是否合法啊，路径的字符串是不是真正的指向的一个路径资源等等。。。