Почему рендеры клеток часто расширяют JLabel?

Question

Я заметил, что это часто встречается. Например, DefaultListCellRenderer, DefaultTableCellRenderer и DefaultTreeCellRenderer все используют его. Также многие пользовательские средства визуализации ячеек, которые я вижу в Интернете, также используют это. Я хочу использовать пользовательский TableCellRenderer в своем коде, но я не уверен, действительно ли мне нужен подкласс JLabel. В чем выгода от создания подклассов JLabel?

Answer 1

API для DefaultTableCellRenderer заявляет:

Класс таблицы определяет средство визуализации одной ячейки и использует его как штамп для отображения всех ячеек в таблице.;он отображает первую ячейку, изменяет содержимое средства визуализации этой ячейки, перемещает источник в новое местоположение, перерисовывает его и т. д.Стандартный компонент JLabel не был разработан для использования таким образом, и мы хотим избежать срабатывания revalidate каждый раз при отрисовке ячейки.Это значительно снизит производительность, поскольку сообщение revalidate будет передаваться по иерархии контейнера, чтобы определить, будут ли затронуты какие-либо другие компоненты.Поскольку средство рендеринга используется только для жизненного цикла операции рисования, мы также хотим избежать издержек, связанных с обходом иерархии для операций рисования.Таким образом, этот класс переопределяет методы validate, invalidate, revalidate, repaint и firePropertyChange на no-ops и переопределяет метод isOpaque исключительно для повышения производительности.Если вы пишете свой собственный рендерер, помните об этом производительности.

Answer 2

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

Answer 3

Потому что каждый - даже ранняя команда Swing - имеет право время от времени делать неправильные вещи: -)

И неправильно расширять компонент вместо реализации интерфейса рендерераи пусть эта реализация делегирует компоненту (который может быть специально реализованным JLabel со всеми свистками, которые они считают необходимыми, лично я не уверен).Мы все еще страдаем от этого плохого решения о реализации - зловещая «цветовая память» DefaultTableCellRenderer является прямым следствием.

Итак: Do-not-subclass-someComponent-to-Implement-someRenderer.Особенно не для некоторого компонента == DefaultTableCellRenderer, он сломан!

Кстати, SwingX все делает правильно: -)