不同领域的设计模式

时间:2011-10-18 10:11:24

标签: java design-patterns

我正在编写一个目录解析器实用程序,它扫描不同目录中的不同类型的文件。

现在一个简单的实现促使我做以下事情。 有一个要解析的目录列表,循环它们并将它传递给实际执行文件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()方法移动到抽象目录类是否有意义?

3 个答案:

答案 0 :(得分:3)

我不认为将文件名搜索模式作为Dir的一部分是一个很好的设计。但是,封装FileSearchDir的{​​{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)

几点:

  • 我不建议将该模式作为目录的一部分。
  • 模式应该是实现某些接口的对象的一部分,如:IParser 它有一个方法,它接受一个目录对象并根据需要进行解析。
  • 您可以为扩展,文件长度等提供不同的IParser实现。