Шаблон проектирования для различных полей

Question

Я пишу утилиту синтаксического анализа каталогов, которая сканирует разные каталоги для разных типов файлов.

Теперь простая реализация побуждает меня сделать следующее. Есть список каталогов для анализа, циклический просмотр и передача его методу, который фактически выполняет файловый ввод-вывод и другую логику и возвращает результат.

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 и Pattern, может быть хорошим дизайном.

Еще одна вещь, о которой стоит подумать, это то, что Apache Commons FileUtils предоставляет такую ​​функциональность в методе listFiles, используя IOFileFilter экземпляры, такие как RegexFileFilter.Вы можете создать класс, который включает IOFileFilter для Dir и RegexFileFilter для имени файла.

Answer 2

ОК, я предложу свое решение

1) Создайте интерфейс с именем IFileProcessor, имеющий метод processFile 2) Создать одноэлементные классы, специфичные для типов документов, реализующих IFileProcessor. Таким образом, классы будут DocFileProcessor, XLSFileProcessor и т. Д., И каждый класс будет иметь свою собственную конкретную реализацию API-интерфейса processFile. 3) Создайте класс фабрики, скажем, FileProcessorFactory. Он должен иметь API с именем IFileProcessor getFileProcessor(String fileTypeExtension). Этот API будет принимать расширение файла в качестве входных данных и возвращать DocFileProcessor, XLSFileProcessor и т. Д. Для ввода doc, xls и т. Д. 4) В вашем цикле вызовите getFileProcessor из FileProcessorFactory, предоставив ему ввод. Теперь вызовите processFile для возвращенного экземпляра.

Наличие этого дизайна отделяет логику if-else от Factor, позволяя вам оставаться независимым от типов файлов.

Answer 3

Несколько точек:

• Я не рекомендую иметь шаблон как часть Каталога.
• Шаблоны должны быть частью объекта, который реализует некоторый интерфейс, такой как: IParserимеет метод, который принимает объект каталога и выполняет этот анализ по мере необходимости.
• Вы можете иметь различные реализации IParser для расширения, длины файла и т. д.