一个android文本比对APP的实现（三）－设计模式在文件选择模块中的运用

用惯了windows, 当发觉android没有原生的文件管理器或类似模块的时候，感觉非常不合理。android sdk似乎也没有提供类似的组件以让程序调用，没办法，也就只好自己动手做。当然，我也不是从头开始，网上有很多朋友已经做过了，我拿过来改改，顺便加了点自己的东西。先把实现的效果显示一下：

具体实现大家可以看：http://blog.csdn.net/trbbadboy/article/details/7899424

我使用该朋友的代码时，利用设计模式对原有设计做了改进，在实现文件选择器时，一个问题在于文件的图标如何显示，在原有设计中，文件与图标的对应关系是写死的,伪码如下：

if (fileExtension == "wav") {

setIcon("wav.png");

}

if (fileExtension == "txt") {

setIcon("txt.png");

}

.......

这种方法有一个问题，由于实际运用中，文件种类太多，这样，代码中将会有大量的if else 结构，这样的代码结构导致的问题是无法扩展，当有新的文件类型时，需要改动代码，增加if else分支，当某种文件图标由于升级而改变后，代码需要在众多if else 中找到相应的位置并改动，因此这种代码模式是难以适应需求变化的，无法达到面向对象的设计中，open for extension, closed for modification 的标准，处理这种情况，最好的方法就是运用设计模式中的责任链模式。

为了重构上述代码，我们先定义一个接口，文件选择器要获取文件图标时，调用接口，这样，图标的获取就和文件选择器的逻辑实现解耦合了：

public interface FileIconManager {int getIconByExtension(String extension);}

接着我们将上面的if 实现分别封装到具体的类中，例如，获取二进制文件的图标，我们这么实现：

public class BinaryFileIcon implements FileIconManager{public int getIconByExtension(String extension){return R.drawable.binary;}}

获取wav文件图标，我们这么实现：

public class WavFileIcon extends BinaryFileIcon{    private String wavExtension = "wav";public int getIconByExtension(String extension)    {    if (extension == wavExtension)    {    return R.drawable.wavfile;    }    else    {    return super.getIconByExtension(extension);    }    }}

大家可以发现，如果当前文件的后缀与具体实现类中的需求不一样，那么就把这个请求提交给他的父类，这就相当于原来代码中，一个if不满足，接着判断下一个if. 于是子类和父类构成了一个处理链条。这么做好处比原来一对if else要好很多，一是容易扩张，如果需要添加新的图标，例如需要再添加一个vod后缀的图标，我们只要再重新实现一个类，然后将该类继承于WavFileIcon即可。二是容易更改，当我们要修改某个图标时，只要找到相应的图标类进行修改，而不用影响其他图标的获取代码，保证修改不影响程序的质量。

具体代码的实现，大家可以下载程序代码看看，希望大家多给予批评和指导

更多相关文章

随机推荐