Spring源码学习IOC(1)：Resource的分析

我们知道，在spring中，配置文件是通过资源形式加载的，我们首先来分析一些在spring中资源类的结构，并且查看一下资源的类型;

资源类图如下：



public interface InputStreamSource {

        /**

         *用于获得资源的输入流

         */

    InputStream getInputStream() throws IOException;

}

抽象出这层接口，事实上是把java底层的二进制流和spring中的resource给对应以来，把inputstream包装进Resource；

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的预处理，都是经过了一个工具类来进行的，可以，在总段代码中，我们看见了很多的复用性和组织性，很多细节的方面的值得我们效仿和学习；