Блог

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

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

 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() также в класс абстрактного каталога?

Я не думаю, что наличие шаблона поиска имени файла как части Dir является хорошим дизайном. Однако FileSearch объект, который инкапсулирует Dir и Pattern может быть хорошим дизайном.

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

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

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

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

Несколько моментов:

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