我正在编写一个目录解析器实用程序,它扫描不同目录中的不同类型的文件。
现在一个简单的实现促使我做以下事情。 有一个要解析的目录列表,循环它们并将它传递给实际执行文件I / O和其他逻辑并返回结果的方法。
List<Dir> dirList;
//loop over the list and call parseDirecotry()
parseDirectory(Dir dirToParse){
//do file io
if (filename.matches("pattern"){
//proceed)
}
}
扫描的每个目录都要求我过滤掉某些文件。所以现在 对于certails dir,匹配模式会有所不同,现在我可以继续根据if else逻辑中的目录类型添加匹配模式。 要么 我可以将模式作为Dir对象的一部分,使其成为抽象,让特定的目录实现保持特定的匹配模式。
这样,每次我有一个新目录要扫描时,我都不必触摸parseDirectory方法。
问题是:我可以利用这些设计模式吗?您对上述程序的界面方式有什么看法?您认为将parseDirectory()方法移动到抽象目录类是否有意义?
答案 0 :(得分:3)
我不认为将文件名搜索模式作为Dir
的一部分是一个很好的设计。但是,封装FileSearch
和Dir
的{{1}}对象可能是一个不错的设计。
需要考虑的另一件事是Apache Commons Pattern
使用FileUtils
实例listFiles
方法在IOFileFilter
方法中提供此类功能。您可以创建一个包含RegexFileFilter
的{{1}}和文件名的IOFileFilter
的类。
答案 1 :(得分:1)
好的我会提出我的解决方案
1)创建一个名为IFileProcessor的接口,该接口具有方法processFile
2)创建特定于实现IFileProcessor的文档类型的单例类。所以这些类将是DocFileProcessor,XLSFileProcessor等,每个类都有自己特定的processFile API实现。
3)创建一个工厂类,说FileProcessorFactory。它应该有一个名为IFileProcessor getFileProcessor(String fileTypeExtension)
的API。此API将文件扩展名作为输入,并返回DocFileProcessor,XLSFileProcessor等输入doc,xls等。
4)在你的循环中调用FileProcessorFactory的getFileProcessor给它输入。现在在返回的实例上调用processFile。
将此设计与if-else的逻辑解耦为因子,允许您使逻辑保持独立于文件类型。
答案 2 :(得分:0)
几点: