不同领域的设计模式

Question

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

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

Answer 1

我不认为将文件名搜索模式作为Dir的一部分是一个很好的设计。但是，封装FileSearch和Dir的{​​{1}}对象可能是一个不错的设计。

需要考虑的另一件事是Apache Commons Pattern使用FileUtils实例listFiles方法在IOFileFilter方法中提供此类功能。您可以创建一个包含RegexFileFilter的{​​{1}}和文件名的IOFileFilter的类。

Answer 2

好的我会提出我的解决方案

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的逻辑解耦为因子，允许您使逻辑保持独立于文件类型。

Answer 3

几点：

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