Я пишу библиотеку для обхода файлового дерева и планировал использовать фасад, похожий на java.nio.Files
, чтобы раскрыть метод walk(path, fileTreeVisitor)
. Этот класс Files
stati c будет находиться в пакете fs
.
Я также хочу упростить пропуск файлов и каталогов, поэтому я собирался реализовать FilteringFileTreeVisitor
, который использует FilePredicate
s для фильтрации файлов и каталогов.
Может быть много реализации FilePredicate
(например, FilenameMatches
, FileSizeBetween
, et c.).
С моей точки зрения, у меня есть как минимум 3 варианта упаковки:
Поместите интерфейс FilePredicate
и все реализации в пакет fs
... Это может сделать пакет fs
постоянно растущим по мере добавления новых реализаций.
Поместить Интерфейс FilePredicate
и реализации в пакете fs.filepredicate
... Теперь клиенты пакета fs
также должны импортировать пакет fs.filepredicate
просто для вызова fs.Files.walk
. Если посмотреть на java, то java.nio.Files.newBufferedReader
может зависеть от java.nio.charset.Charset
, поэтому, возможно, здесь не о чем беспокоиться.
Поместите интерфейс FilePredicate
в пакет fs
вместе с наиболее распространенными реализациями предикатов и помещением менее распространенных в fs.filepredicate
... Использование fs.Files.walk
не потребовало бы дополнительного импорта для стандартных случаев, но теперь предикаты разбросаны по двум пакетам, и, вероятно, не существует универсального способа определение того, какие предикаты будут широко использоваться.
Я не уверен, какой правильный звонок здесь?