我们知道,在spring中,配置文件是通过资源形式加载的,我们首先来分析一些在spring中资源类的结构,并且查看一下资源的类型;
资源类图如下:
抽象出这层接口,事实上是把java底层的二进制流和spring中的resource给对应以来,把inputstream包装进Resource;
进一步抽象出Resource的功能接口,在这里,我们可以看出,在代码编写过程中,接口的设计是根据逻辑一步一步抽象出来的,不用吝啬接口的生成,按照接口隔离原则;
抽象出来的Resource功能接口对于下面多种不同类型的资源,其有很多功能接口的实现势必是相同的,所以在这里spring建立了一个抽象类,在设计模式中,抽象类应该做到的是,尽量把子类相同的功能方法放到抽象父类中实现,增加复用,而尽量把少的数据推到子类中实现,减少空间的消耗;
在这类Resource中,我们使用得最多的,估计就是要属于ClassPathResource和FileSystemReource;顾名思意,这两种资源类分别是默认在ClassPath和FileSystem下查找资源;而我们用得最多的是classPath,因为这样对工程的移植更有利;
public class FileSystemResource extends AbstractResource {
private final File file;
private final String path;
public FileSystemResource(File file) {
Assert.notNull(file, "File must not be null");
this.file = file;
this.path = StringUtils.cleanPath(file.getPath());
}
public FileSystemResource(String path) {
Assert.notNull(path, "Path must not be null");
this.file = new File(path);
this.path = StringUtils.cleanPath(path);
}
public final String getPath() {
return this.path;
}
public boolean exists() {
return this.file.exists();
}
public InputStream getInputStream() throws IOException {
return new FileInputStream(this.file);
}
public URL getURL() throws IOException {
return new URL(ResourceUtils.FILE_URL_PREFIX + this.file.getAbsolutePath());
}
public File getFile() {
return file;
}
public Resource createRelative(String relativePath) {
String pathToUse = StringUtils.applyRelativePath(this.path, relativePath);
return new FileSystemResource(pathToUse);
}
public String getFilename() {
return this.file.getName();
}
public String getDescription() {
return "file [" + this.file.getAbsolutePath() + "]";
}
public boolean equals(Object obj) {
return (obj == this ||
(obj instanceof FileSystemResource && this.path.equals(((FileSystemResource) obj).path)));
}
public int hashCode() {
return this.path.hashCode();
}
}
在VStringUtil中,我们可以看见如下代码:
public static String replace(String inString, String oldPattern, String newPattern) {
if (inString == null) {
return null;
}
if (oldPattern == null || newPattern == null) {
return inString;
}
StringBuffer sbuf = new StringBuffer();
// output StringBuffer we'll build up
int pos = 0; // our position in the old string
int index = inString.indexOf(oldPattern);
// the index of an occurrence we've found, or -1
int patLen = oldPattern.length();
while (index >= 0) {
sbuf.append(inString.substring(pos, index));
sbuf.append(newPattern);
pos = index + patLen;
index = inString.indexOf(oldPattern, pos);
}
sbuf.append(inString.substring(pos));
// remember to append any characters to the right of a match
return sbuf.toString();
}
是将//tihuan成/的代码,我们可见,在这段代码中,对传入的参数进行了严密的验证,正如代码大全中所介绍的防御性编程,我们假定从public传入进来的参数都是不安全的,只有在私有方法中,我们才对传入的参数不进行合法验证;
在这里,我们很明显的看出,代码中使用了适配器模式中的类适配器,在新的接口中,我们用resource接口包装了File,
在新的接口中,我们依然能访问file的isExist方法,却丝毫不知道我们是用的file;
其中,StrigUtils类是一个工具,他对path进行了预处理,处理了如//分解符和. ..等文件路径描述的特殊操作符
另外的byte等资源,跟bye和ByteInputeStream的关系是类似的,分别是把不同源的数据当作资源,不过ClasspathResource不同的是,你可以传入ClassLoader或者Class来制定当前的类加载器,从而可以确定资源文件的BascDir
如果你不制定classLoader的话和Class的话,那么就会默认是当前线程的ClassLoader,而在这里,PATH和ClassLoader的预处理,都是经过了一个工具类来进行的,可以,在总段代码中,我们看见了很多的复用性和组织性,很多细节的方面的值得我们效仿和学习;
资源类图如下:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/turkeyzhou/EntryImages/20080907/resource_spring.jpg)
- public interface InputStreamSource {
- /**
- *用于获得资源的输入流
- */
- InputStream getInputStream() throws IOException;
- }
- public interface Resource extends InputStreamSource {
- boolean exists();
- boolean isOpen();
- URL getURL() throws IOException;
- File getFile() throws IOException;
- Resource createRelative(String relativePath) throws IOException;
- String getDescription();
- }
进一步抽象出Resource的功能接口,在这里,我们可以看出,在代码编写过程中,接口的设计是根据逻辑一步一步抽象出来的,不用吝啬接口的生成,按照接口隔离原则;
- import java.io.File;
- import java.io.FileNotFoundException;
- import java.io.IOException;
- import java.io.InputStream;
- import java.net.URL;
-
- /**
- * Convenience base class for {@link Resource} implementations,
- * pre-implementing typical behavior.
- *
- * <p>The "exists" method will check whether a File or InputStream can
- * be opened; "isOpen" will always return false; "getURL" and "getFile"
- * throw an exception; and "toString" will return the description.
- *
- * @author Juergen Hoeller
- * @since 28.12.2003
- */
- public abstract class AbstractResource implements Resource {
- public boolean exists() {
- // Try file existence: can we find the file in the file system?
- try {
- return getFile().exists();
- }
- catch (IOException ex) {
- // Fall back to stream existence: can we open the stream?
- try {
- InputStream is = getInputStream();
- is.close();
- return true;
- }
- catch (Throwable isEx) {
- return false;
- }
- }
- }
- public boolean isOpen() {
- return false;
- }
- public URL getURL() throws IOException {
- throw new FileNotFoundException(getDescription() + " cannot be resolved to URL");
- }
- public File getFile() throws IOException {
- throw new FileNotFoundException(getDescription() + " cannot be resolved to absolute file path");
- }
- public Resource createRelative(String relativePath) throws IOException {
- throw new FileNotFoundException("Cannot create a relative resource for " + getDescription());
- }
- public String getFilename() throws IllegalStateException {
- throw new IllegalStateException(getDescription() + " does not carry a filename");
- }
- public abstract String getDescription();
- public String toString() {
- return getDescription();
- }
- public boolean equals(Object obj) {
- return (obj == this ||
- (obj instanceof Resource && ((Resource) obj).getDescription().equals(getDescription())));
- }
- public int hashCode() {
- return getDescription().hashCode();
- }
抽象出来的Resource功能接口对于下面多种不同类型的资源,其有很多功能接口的实现势必是相同的,所以在这里spring建立了一个抽象类,在设计模式中,抽象类应该做到的是,尽量把子类相同的功能方法放到抽象父类中实现,增加复用,而尽量把少的数据推到子类中实现,减少空间的消耗;
在这类Resource中,我们使用得最多的,估计就是要属于ClassPathResource和FileSystemReource;顾名思意,这两种资源类分别是默认在ClassPath和FileSystem下查找资源;而我们用得最多的是classPath,因为这样对工程的移植更有利;
public class FileSystemResource extends AbstractResource {
private final File file;
private final String path;
public FileSystemResource(File file) {
Assert.notNull(file, "File must not be null");
this.file = file;
this.path = StringUtils.cleanPath(file.getPath());
}
public FileSystemResource(String path) {
Assert.notNull(path, "Path must not be null");
this.file = new File(path);
this.path = StringUtils.cleanPath(path);
}
public final String getPath() {
return this.path;
}
public boolean exists() {
return this.file.exists();
}
public InputStream getInputStream() throws IOException {
return new FileInputStream(this.file);
}
public URL getURL() throws IOException {
return new URL(ResourceUtils.FILE_URL_PREFIX + this.file.getAbsolutePath());
}
public File getFile() {
return file;
}
public Resource createRelative(String relativePath) {
String pathToUse = StringUtils.applyRelativePath(this.path, relativePath);
return new FileSystemResource(pathToUse);
}
public String getFilename() {
return this.file.getName();
}
public String getDescription() {
return "file [" + this.file.getAbsolutePath() + "]";
}
public boolean equals(Object obj) {
return (obj == this ||
(obj instanceof FileSystemResource && this.path.equals(((FileSystemResource) obj).path)));
}
public int hashCode() {
return this.path.hashCode();
}
}
在VStringUtil中,我们可以看见如下代码:
public static String replace(String inString, String oldPattern, String newPattern) {
if (inString == null) {
return null;
}
if (oldPattern == null || newPattern == null) {
return inString;
}
StringBuffer sbuf = new StringBuffer();
// output StringBuffer we'll build up
int pos = 0; // our position in the old string
int index = inString.indexOf(oldPattern);
// the index of an occurrence we've found, or -1
int patLen = oldPattern.length();
while (index >= 0) {
sbuf.append(inString.substring(pos, index));
sbuf.append(newPattern);
pos = index + patLen;
index = inString.indexOf(oldPattern, pos);
}
sbuf.append(inString.substring(pos));
// remember to append any characters to the right of a match
return sbuf.toString();
}
是将//tihuan成/的代码,我们可见,在这段代码中,对传入的参数进行了严密的验证,正如代码大全中所介绍的防御性编程,我们假定从public传入进来的参数都是不安全的,只有在私有方法中,我们才对传入的参数不进行合法验证;
在这里,我们很明显的看出,代码中使用了适配器模式中的类适配器,在新的接口中,我们用resource接口包装了File,
在新的接口中,我们依然能访问file的isExist方法,却丝毫不知道我们是用的file;
其中,StrigUtils类是一个工具,他对path进行了预处理,处理了如//分解符和. ..等文件路径描述的特殊操作符
另外的byte等资源,跟bye和ByteInputeStream的关系是类似的,分别是把不同源的数据当作资源,不过ClasspathResource不同的是,你可以传入ClassLoader或者Class来制定当前的类加载器,从而可以确定资源文件的BascDir
如果你不制定classLoader的话和Class的话,那么就会默认是当前线程的ClassLoader,而在这里,PATH和ClassLoader的预处理,都是经过了一个工具类来进行的,可以,在总段代码中,我们看见了很多的复用性和组织性,很多细节的方面的值得我们效仿和学习;