菜鸟的spring 3.0源码学习之旅（1）

大家好，从今天开始，由我来讲解spring 3.0，希望大家多多捧场，提出批评

首先呢，我先介绍一下我自己吧，我呢叫小辞，20岁的小伙子，为了提升自己，为了和大家共同交流技术，所以，我把我每天学习spring 3.0源码的心得和经验还有自己的一点小小的体会与大家分享，希望大家多多捧场啦

还有呢，因为本人并不算是一个严格意义上的大学生（电气自动化的成考大专，你们懂的）,所以呢，还有本人经验以及知识上的不足，我所说的东西不一定就是对的，希望大家怀着怀疑的心态去阅读我的体会。可能话相当的罗嗦，但是没办法，这就是我的思维，考虑的尽量全面一点，罗嗦就罗嗦吧，再说了，我也是一个菜鸟，菜鸟当然会对一些基础的，高手们不屑一顾的东西关心不已嘛。。。理解万岁吧

那么，开始正题吧

我想，大家对于org.springframework.core.io.Resource接口不是很陌生，今天呢，我们就讲解这个类以及它的子类org.springframework.core.io.FileSystemResource(如不特殊说明，今天所有的类都位于org.springframework.core.io包下面)

首先呢，我们先看一下他们的机构，Resource是一个接口，由AbstractResource抽象类实现部分公用的方法，然后呢，由各个子类去分别实现AbstractResource抽象类

对于Resource，我觉得没有什么好讲的，接口嘛。。。大家懂的，但是呢对于AbstractResource，我却产生了比较浓厚的兴趣，首先呢，在于它对于接口定义的那些方法的实现上面，比如说，大家看一下其中的几个语句

Org.springframework.core.io.AbstractResource#isReadable()

public boolean isReadable() {

              return true;

}

Org.springframework.core.io.AbstractResource#isReadable()

public File getFile() throws IOException {

       throw new FileNotFoundException(getDescription() + " cannot be resolved to absolute file path");

}

我想大家对于这两个语句不是很陌生，但是奇怪的就在于，为什么在这个方法里，它总是返回true，而对于第二个方法来说，它则是直接的抛出一个异常？

我想聪明的大家应该会很快的明白，这些其实是为了让子类去覆盖它们，也就是说，假如它们的实现类没有覆盖AbstractResource相应的方法的话，它们很可能会抛出异常，或者是这个方法很可能会失效

那么为什么要这么写呢？

我想地球人都知道，抽象类本身就是对于那些实现类高度抽象以后的结果，也就是说，这些方法都是以后它们的子类实现类必须需要实现的方法，因为每一个实现类对于每一个相同的方法的实现都不太相同，所以在抽象类中，考虑的主要就是假如实现类没有实现我的这个方法，我就必须要告知它们，或者抛出异常，或者失效

那么大家又可能会问，如果要是按照上面说的话的意思的话，那么这个AbstractResource岂不是可有可无呢，我想应该不是的，因为在这里并不是所有的方法都必须被覆盖，可能有基础不是很好的童鞋们可能会担心假如实现了这个抽象类是不是完全不能使用呢，那么，我可以很严肃的告诉你，抽象类以及接口是不能被实例化的，所以你们就大大的放心好了，不过可以用静态方法哦！

在很久很久以前，每当我看到大婶们写的那些非常牛的框架里，都喜欢加一个toString方法，以前觉得特神秘，有种大婶一样的气势！不过问了度娘才知道，这个方法是用来进行调试的，至于怎么调试呢，给个悬念啦

对于在Resource以及子类里，我个人实在理解不了getDescription()方法和toString()方法有什么不同

Org.springframework.core.io.AbstractResource#toString()

public String toString() {

       return getDescription();

}

好嘛。。。。既然是用getDescription()方法实现的，那么完全就没必要写两个方法嘛，

Org.springframework.core.io.FileSystemResource#getDescription

public String getDescription() {

       return "file [" + this.file.getAbsolutePath() + "]";

}

对于这个呢？我更加理解不了了，在我看来，完全就没必要这么写嘛。。。直接用file.toString()就好了嘛。难道是这样写觉得很酷？很正规？在这里还是求大神们解释下拉

在FileSystemResource类里，有两个字段

private final File file;

private final String path;

有了这两个字段，让我更加相信了Resource的底层用的其实还是File类以及它的方法，这个file文件还是private final的，并且没有相应的getter,setter方法，有这个我们可以知道，它的内核是隐藏的，不许修改的，但是这个又比File文件更加的规范，功能也更加全面，也更加的强壮，例如下面这个代码

Org.springframework.core.io.FileSystemResource#isReadable()

public boolean isReadable() {

       return (this.file.canRead() && !this.file.isDirectory());

}

当我看到这个方法的时候，我才恍然大悟，原来在File文件里，对于目录是可读可写可执行的，当时我和小伙伴们都惊呆了，如果要是对于一个普通的txt文件来说，那么它是可读可写的，那么它的路径也是可读可写的，那么我们就有必要规范一下，在不是目录的情况下的文件时可读的，那才返回true，

以前我一直问自己，哈希码有什么用，我想在这里，它的用处其实就是一个身份证号码，用来确定引用的是不是同一个底层文件

Org.springframework.core.io.FileSystemResource#hashCode()

public int hashCode() {

       return this.path.hashCode();

}

恩恩。。。我再让大家看一个构造器

public FileSystemResource(File file) {

       Assert.notNull(file, "File must not be null");    //确保file不为null

       this.file = file;

       this.path = StringUtils.cleanPath(file.getPath()); 

}

很显然，这个是FileSystemResource的构造器，但是呢大家注意到没有，它的第一句是进行不为空的检查，如果文件为空，则抛出异常，其实吧，这个也好理解，这个文件的核心就是file文件，如果核心都为null了，那么别的就没必要说了

另外呢，我再讲解一个有关工具类的吧

public static String trimLeadingCharacter(String str, char leadingCharacter) {

       if (!hasLength(str)) {

              return str;

       }

       StringBuilder sb = new StringBuilder(str);

       while (sb.length() > 0 && sb.charAt(0) == leadingCharacter) {

              sb.deleteCharAt(0);

}

       return sb.toString();

}

在这里呢，我觉得这个StringBuilder写的很好，用它来进行字符串中字符的增减，节能又环保啊，所以我比较推荐在对于字符串中字符的增删的修改中，用StringBuilder或许是一个比较不错的选择

好了，哥们困了，该睡觉觉去了，单身好寂寞呀。。。。。。。。晚安

                                                                                                                      小辞