TreeModel действительно так плохо, как я думаю?

Question

Когда я впервые увидел javax.swing.tree.TreeModel, я подумал, что написать все методы - довольно много работы. Затем я нашел DefaultTreeModel и подумал, что его будет легко использовать для дерева файлов через шаблон адаптера. Таким образом, я начал писать адаптер и вроде не удалось. Мне нужно иметь доступ к соответствующему файлу с TreeNode (что легко, поскольку это может быть переменная экземпляра), но мне нужен и другой способ. Это можно решить с помощью карты, но она потребляет довольно много памяти. Помогло переключение на WeakHashMap.

Это сработало, но я столкнулся с некоторыми странными проблемами, когда дерево изменилось. Кроме того, все было очень медленно, так как File.list() вызывали много раз. Существует несколько глупых методов, таких как getChildCount(), getChild(Object parent, int index) и getIndexOfChild(Object parent, Object child), и в моей простой реализации каждый вызов приводит к чтению каталога.

Все это было довольно много работы, и результат был ужасен. Конечно, я виноват, но не было ли это прямым следствием использования некорректной, слишком сложной модели?

Этого бы не произошло, если бы вместо этого был один метод, такой как List getChildren(Object). Может я все сделал не так, как правильно?

^{Наконец, я написал MyCachingTreeModel implements TreeModel, используя адаптер на класс , что решило все проблемы. Но мне все еще интересно, как еще это можно было решить.}

Обновление:

Вышесказанное может выглядеть как напыщенная речь, а не как правильный вопрос. Поэтому я попробую еще раз:

Как эффективно реализовать TreeModel для дерева файловой системы, чтобы он отображал текущее состояние каталогов?

^{Мое решение здесь не считается, так как я обошел всю модель. Более того, он слишком много кеширует и почти не замечает каких-либо изменений.}

Answer 1

(довольно позднее редактирование:)

Как эффективно реализовать TreeModel для дерева файловой системы, чтобы он отображал текущее состояние каталогов?

Я думаю, что нет действительно хорошего способа показать дерево каталогов с помощью JTree, поэтому оно всегда актуально. Проблема в том, что модель должна уведомлять своих слушателей (= JTree) о любых важных изменениях, и это возможно только в том случае, если мы регулярно перепроверяем файлы. Так что вашей модели, по крайней мере, понадобится собственный поток. Естественно, он должен проверять только те файлы, чьи узлы на самом деле отображаются, но модель на самом деле не знает этого (может догадаться только по последним вызовам getValue()).

Возможно, это можно совместить с проблемой кеширования: иметь кеш объектов каталога, соответствующих последним запрашиваемым узлам, со временем «последней проверки». В течение некоторого времени после первого создания они остаются действительными, мы кешируем список дочерних файлов, но выбрасываем их позже. Для тех же объектов, которые были запрошены деревом, мы также через некоторое время снова посмотрим на файловую систему и сгенерируем правильные события изменения, когда что-то не так, как раньше.

Это все еще зависит от большого количества эвристик, чтобы знать, какие файлы нужно проверять - может быть, вместо этого нам следует разбить наслоение и позволить нашей модели просто спрашивать дерево, какие узлы показывают, перепроверяя (и кэшируя) только те.

---

(Старый не совсем ответ:)

Когда API TreeModel был создан (в то же время, что и весь Swing), Framework коллекции еще не было. Это также причина того, что нам нужен вектор (вместо списка) в нескольких местах в Swing.

Answer 2

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

При этом не похоже, что это действительно адекватно отражено в спецификации API, иначе вам не пришлось бы задавать вопрос. :)

Answer 3

Также: рассмотрим платформу NetBeans и их API Node & Explorer