悠然乱弹:从几个方法的重构讲开去--文件相关的处理

简单看看吧,确实没有什么好的解决方案,那我们就抽丝剥茧,看看这三个方法里都涉及到哪些个领域?

  1. 涉及到注解方面的处理
  2. 涉及到多种注解方面的处理
  3. 涉及到文件查找方面的问题
  4. 涉及到多种资源文件查找方面的问题-file,jar
  5. 涉及到对查找到资源文件之后的后续处理的问题

好吧,可能还有别的问题,我们先利用上面分析出来的问题,看看有没有着手之处??

仔细分析下来,暂时有三种要遍历的文件了,file,jar,自定义ClassLoader,那我们简单抽象一下:

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

public interface FileObject{

     String getFileName(); <span></span>      

     String getFileExtName();

     List<FileObject> getSubFileObject();

     void foreach( FileObjectFilter fileObjectFilter,FileObjectProcessor fileObjectProcessor);

     ...

}

然后构建

三个实现类:

public class FileObjectImpl implements FileObject{

...

}

public class JarFileObjectImpl implements FileObject{

...

}

public class ClassLoaderFileObjectImpl implements FileObject{

...

}

这样一来就把不同的文件类型分解了。

在后续的处理中,就只要写:

?


1

2

3

for(FileObject fileObject:fileObjects){

...

}

而不用再写烦人的if(protocal.equals("file"), if(protocal.equals("jar")等等了,关键是后面不管再来多少种类型,咱的处理逻辑也不用再进行调整了。

接下来呢,肯定要进行文件的查找与处理,咋办呢??抄,在JDK中有个FileFilter,咱给他来个FileObjectFileter不就解了??

?


1

2

3

public interface FileObjectFilter {

    public boolean accept(FileObject fileObject);

}

那后续还要处理呢?再来个FileObjectProcessor

?


1

2

3

public interface FileObjectProcessor {

    void process(FileObject fileObject);

}

那不是还要递归做循环找文件么?写个递归处理方法:

?


1

2

3

4

5

6

7

8

public void foreach(FileObjectFilter fileObjectFilter,

                               FileObjectProcessor fileObjectProcessor) {

        if (fileObjectFilter.accept(this)) {

            fileObjectProcessor.process(this);

        }

            for (FileObject subFileObject : getChildren()) {

                foreach(subFileObject, fileObjectFilter, fileObjectProcessor, parentFirst);

            } <span></span> }

那咱要找个所有的class文件,怎么找呢??先写个文件扩展名过滤器

?


1

2

3

4

5

6

7

8

9

10

11

12

13

public class FileExtNameFileObjectFilter implements FileObjectFilter {

    String fileExtName;

    public FileExtNameFileObjectFilter(String fileExtName) {

        this.fileExtName = fileExtName;

    }

    public boolean accept(FileObject fileObject) {

        String extName = fileObject.getExtName();

        if (extName != null) {

                return extName.equals(fileExtName);

        }

        return false;

    }

}

接下来就如此这般了:

?


1

2

3

4

5

fileObject.foreach(new FileExtNameFileObjectFilter("class"),new FileObjectProcessor() {

    public void process(FileObject fileObject) {

        System.out.println(fileObject.getPath());

    }

});

OK,到此为止,各种文件的支持与遍历,过滤处理已经有比较好的解决方案了。

代码写起来很容易,扩展起来也很方便。可以满意了。

那么上面的代码可以处理为:

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

fileObject.foreach(new AnnotationFileObjectFilter(Abc.class),new FileObjectProcessor() {

    public void process(FileObject fileObject) {

        Class clazz=Class.forName(fileObject.getFileName);

        //做处理处理的一些事情

    }

});

 

fileObject.foreach(new AnnotationFileObjectFilter(Def.class),new FileObjectProcessor() {

    public void process(FileObject fileObject) {

        Class clazz=Class.forName(fileObject.getFileName);

        //做处理处理的一些事情

    }

});

...

在文件处理方面比原来的形式好多了,但是上面提到的性能问题还是存在的。

胖子不是一口吃成的,罗马不是一天到达的,这篇先到这儿,下篇再看注解相关的处理。

时间: 2024-09-14 05:25:19

悠然乱弹:从几个方法的重构讲开去--文件相关的处理的相关文章

悠然乱弹:从几个方法的重构讲开去--注解相关的处理

有时候它们的处理没有关联性,有些时候,它们的处理又是有关联性的. 我们用伪代码来示意一下. ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 if(includeAnnotation(testClass,Abc.class)){   doSomething... }   if(includeAnnotation(testClass,Abc.class)){   for(Field field:testClass.getFields){     if(include

悠然乱弹:从几个方法的重构讲开去--性能大优化

现在还存在多次扫描处理的问题,也就是说虽然代码结构性重构是成功的,但是性能问题还是没有根本解决. 在给出解决方案之前,需要对这个处理方式缕一缕: 处理方式1:每次遍历全路径找到待处理文件,文件然后批量进行处理.优点是处理起来比较简单,但是会重复扫描. 处理方式2:一次遍历所有文件,然后对每个文件进行注解检测.扫描全路径只有一次,然后要把每个文件与过滤器进行比较如果比较成功那就做,比较不成功就不做. 稍加分析就会发现,两种方式的比较次数是一样的,但是第二种方案遍历文件的次数就少到极限了,还能比1次

悠然乱弹:从几个方法的重构讲开去--引言

引言: 在学习代码的过程中,看到如下几个工具方法: ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77

悠然乱弹:从一段代码讲开去

序言 今天偶然看到一框架,在框架的里面有一段这样的描述: ? 1 2 xxx并不愿意其他人来直接修改YYY框架的代码,因为XXX致力于将它打造为完美的作品,其他人写的代码,实在没有加入进来的意义. 但是您可以当小白鼠,提意见,提bug,好的idea我还是愿意接受的. 这里解释一下,其中xxx是作者名字,YYY是框架名称,这么OSC上牛人众多,牛到这个程度的还是第一次见到,于是就想去速度学习一下.其实框架好不好,看例子代码就可以看出一二,去找了找,果然找到了示例代码,我摘了两个方法: ? 1 2

悠然乱弹:一段SQL引发的性能危机及其背后隐藏的设计缺陷

故事发生的背景是,在文件上传的时候,有时间会有人上传了文件,但是最后没有使用上传的文件,这样就会产生一些垃圾文件. 原来软件作者就想写一个后台定时任务程序,来清除这些垃圾文件? 由于作者坚定的不让我发她的SQL语句(这个我也理解,这么丑陋的SQL),所以这里就不发源代码了,发伪代码. ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void deleteMissLinkFile{   List fileList=getFileList();   List delete

悠然乱弹:螺旋矩阵和蛇型矩阵的悠然版实现

螺旋矩阵和蛇型矩阵,是两个比较有趣的矩阵,有许多的公司面试题中有出现,这两个题的答案也有许多种,简单问一下度娘,就各自有N种实现,来源也非常丰富,比如CSDN.ITEYE.等等,当然也包括著名的OSC,但是整体看下来,呵呵,比较顺眼的比较少,比较经典的就越发少了. 考虑到不同的语言有不同的语言特性,因此今天就只用Java来进行实现,看看螺旋矩阵和蛇型矩阵的悠然版实现,让我们的OSC也更加高大上一些,. 概念说明 什么是螺旋矩阵 螺旋矩阵是指一个呈螺旋状的矩阵,它的数字由第一行开始到右边不断变大,

工厂方法真的支持OCP 开闭原则吗?

问题描述 工厂方法真的支持OCP 开闭原则吗? 开闭原则:我们在设计一个模块的时候应当使这个模块可以在不被修改的前提下被扩展换句话说就是应当可以在不必修改源代码的情况下改变这个模块的行为.工厂方法增加新的方法类的时候,不是要修改接口.然后再修改所有的相关类么.这岂不是违背了开闭原则 解决方案 工厂什么的都只是假象,利用反射可以

win7系统发生蓝屏打不开DMP文件的解决方法

  最近很多小编询问说ghost win7系统发生蓝屏打不开DMP文件,怎么办?DMP是系统错误产生的文件,当电脑发生蓝屏时,电脑就会生成一个蓝屏错误DMP文件和蓝屏图片,用户想打开DMP文件时发现,DMP文件根本打不开,到底是怎么回事呢?下面小编以Win7 64位系统为例,给大家介绍win7系统发生蓝屏打不开DMP文件的解决方法. 方法如下: 1.首先要下载安装Debugging Tools这个工具; 2.安装好了以后,在开始菜单下面的可以找得到一个[Debugging Tools for W

在aspx前台中 我有一个方法 在后台我要去调用它 怎么解决??

问题描述 在aspx前台中 我有一个方法 在后台我要去调用它 怎么解决?? function exportChangeStatus() { $(""#lblProcess"").css(""display""none""); $(""#btnExport"").css(""display""block"");