用惯了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;
}
}
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即可。二是容易更改,当我们要修改某个图标时,只要找到相应的图标类进行修改,而不用影响其他图标的获取代码,保证修改不影响程序的质量。
具体代码的实现,大家可以下载程序代码看看,希望大家多给予批评和指导