在 Java 中，将不同来源的资源抽象成 ``URL` ,通过注册不同的 `handler` ( `URLStreamHandler`` ) 来处理不同来源的资源的读取逻辑。
然而 ``URL`` 没有默认定义相对 Classpath 或 ServletContext 等资源的 handler ，虽然可以注册自己的 URLStreamHandler 来解析特定的 URL 前缀(协议)。但是 URL 也没有提供基本的方法、如检查当前资源是否存在，检查资源是否存在等方法。
URL: 我可以加载各种的资源.......XXX
Spring: 你是个好人
Spring 实现了自己的资源加载策略
职能划分清楚。资源的定义和资源的加载有明确的界限
统一的抽象，统一的资源定义和资源加载策略。
统一资源
``org.springframework.core.io.Resource`` 接口抽象了所有 Spring 内部使用到的底层资源，如 File、URL、Classpath。
public interface Resource extends InputStreamSource {
.......
.......
}
而 ``org.springframework.core.io.InputStreamSource`` 封装任何能返回 InputStream 的类、如 File、Classpath 下的资源和 ByteArray，该接口只有一个方法 getInputStream
public interface InputStreamSource {
* 表示任意形式的资源都可以被转换成输入流、最好每一次调用这个方法的时候都是返回一个新的InputStream
* 看子类{@link FileSystemResource}符合这个要求
*/
InputStream getInputStream() throws IOException;
}
Resource 接口提供了比 URL 更加多和便捷的方法
对于不同来源的资源文件都有相应的 Resource 实现
文件 FileSystemResource
classpath 资源 ClassPathResource
url 资源 URLResource
InputStream 资源 InputStreamResource
byte 数组资源 ByteArrayResource
其中 AbstractResource 实现了 Resource 接口中大多数的方法，如果我们要自定义 Resource ，可以继承这个类，而不是直接实现 Resource
统一资源加载
``org.springframework.core.io.ResourceLoader`` 是 Spring 资源加载的抽象
public interface ResourceLoader {
* Pseudo URL prefix for loading from the class path: "classpath:".
*/
String CLASSPATH_URL_PREFIX = ResourceUtils.CLASSPATH_URL_PREFIX;
* 根据 资源路径 返回一个Resource 句柄、但不确保这个Resource 一定存在、需要调用 Resource exists 方法 * 判断
* URL位置资源，如”file:C:/test.dat”
* ClassPath位置资源，如”classpath:test.dat”
* 相对路径资源，如”WEB-INF/test.dat”，此时返回的Resource实例根据实现不同而不同
*
* 要可重用、可多次调用 getInputStream
*/
Resource getResource(String location);
@Nullable
ClassLoader getClassLoader();
}
主要实现类就是 ``DefaultResourceLoader` ，其中最核心的方法就是 `getResource``
@Override
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
for (ProtocolResolver protocolResolver : getProtocolResolvers()) {
Resource resource = protocolResolver.resolve(location, this);
if (resource != null) {
return resource;
}
}
if (location.startsWith("/")) {
return getResourceByPath(location);
} else if (location.startsWith(CLASSPATH_URL_PREFIX)) {
return new ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()), getClassLoader());
} else {
try {
URL url = new URL(location);
return (ResourceUtils.isFileURL(url) ? new FileUrlResource(url) : new UrlResource(url));
} catch (MalformedURLException ex) {
return getResourceByPath(location);
}
}
}
其中 ``ProtocolResolver``
@FunctionalInterface
public interface ProtocolResolver {
@Nullable
Resource resolve(String location, ResourceLoader resourceLoader);
}
主要用于处理用户自定义资源协议的，我们可以通过实现此接口来解释我们自定义的资源协议，只需要将实现类对象添加到 ``DefaultResourceLoader`` 中
public void addProtocolResolver(ProtocolResolver resolver) {
Assert.notNull(resolver, "ProtocolResolver must not be null");
this.protocolResolvers.add(resolver);
}
ResourcePatternResolver
在 ResourceLoader 接口的基础上增加了 ``Resource[] getResources(String locationPattern)`` 方法，支持根据指定的路径匹配模式每次返回多个 Resource 实例。
@Override
public Resource[] getResources(String locationPattern) throws IOException {
Assert.notNull(locationPattern, "Location pattern must not be null");
if (locationPattern.startsWith(CLASSPATH_ALL_URL_PREFIX)) {
if (getPathMatcher().isPattern(locationPattern.substring(CLASSPATH_ALL_URL_PREFIX.length()))) {
return findPathMatchingResources(locationPattern);
}
else {
return findAllClassPathResources(locationPattern.substring(CLASSPATH_ALL_URL_PREFIX.length()));
}
}
else {
int prefixEnd = (locationPattern.startsWith("war:") ? locationPattern.indexOf("*/") + 1 :
locationPattern.indexOf(':') + 1);
if (getPathMatcher().isPattern(locationPattern.substring(prefixEnd))) {
return findPathMatchingResources(locationPattern);
}
else {
return new Resource[] {getResourceLoader().getResource(locationPattern)};
}
}
}
涉及到的设计模式
面试的时候
面试官: 看过什么框架的源码吗
菜鸡的我: 我看过 Spring 的源码
面试官: 那你说说 Spring 中用到了什么设计模式
菜鸡的我: 额....好像...有....我忘记了
责任链模式
在资源定义和资源加载这一块中，我们可以看到在 DefaultResourceLoader 中的 ProtocolResolver，
private final Set<ProtocolResolver> protocolResolvers = new LinkedHashSet<>(4);
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
for (ProtocolResolver protocolResolver : getProtocolResolvers()) {
Resource resource = protocolResolver.resolve(location, this);
if (resource != null) {
return resource;
}
}
.....
.....
一个加载资源的请求，会被其中一个 ProtocolResolver 去解释成一个 Resource 或者没有一个 ProtocolResolver 能处理这个请求并返回一个 Resource (最终被后面的默认解析成Resource)。这一个过程其实算是使用到了责任链模式的，只是不是一个纯正的责任链模式。
阎宏博士的《JAVA与模式》一书中是这样描述责任链（Chain of Responsibility）模式的
责任链模式是一种对象的行为模式。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。
纯与不纯的责任链模式
而对于怎么存储下一个 handler 的引用，当然可以在当前 handler 中存有下一个 handler 的引用，但是更加常用的还是使用数组或者列表将所有 handler 存储起来，然后进行链式调用处理请求，如 servlet 的filter即使如此。
策略模式
不同的 ResourceLoader 对应着不同的资源加载策略
在 ``org.springframework.context.support.GenericApplicationContext`` 类中
public class GenericApplicationContext extends AbstractApplicationContext implements BeanDefinitionRegistry {
private final DefaultListableBeanFactory beanFactory;
@Nullable
private ResourceLoader resourceLoader;
public void setResourceLoader(ResourceLoader resourceLoader) {
this.resourceLoader = resourceLoader;
}
@Override
public Resource getResource(String location) {
if (this.resourceLoader != null) {
return this.resourceLoader.getResource(location);
}
return super.getResource(location);
}
这个不就是策略模式吗
相关文章
Spring 专辑
评论