Как Использовать Модели

У большинства компонентов Swing есть модели. Кнопка (JButton), например, имеет модель (a ButtonModel объект), который хранит состояние кнопки — какова его мнемосхема клавиатуры, включается ли это, выбирается, или нажимается и так далее. У некоторых компонентов есть многоуровневые модели. Список (JList), например, использование a ListModel содержать содержание списка, и a ListSelectionModel отслеживать текущий выбор списка.

Вы часто не должны знать о моделях, что компонент использует. Например, программы, которые используют кнопки обычно, имеют дело непосредственно с JButton объект, и не имеет дело вообще с ButtonModel объект.

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

Модели обладают другими преимуществами, также. Они означают, что данные не копируются между структурами данных программы и таковыми из компонентов Swing. Кроме того, модели автоматически распространяют изменения всем заинтересованным слушателям, облегчающим для GUI остаться в синхронизации с данными. Например, чтобы добавить элементы к списку можно вызвать методы на модель списка. Когда данные модели изменяются, события огней модели к JList и любые другие зарегистрированные слушатели, и GUI обновляются соответственно.

Хотя архитектура модели Swing иногда упоминается как Контроллер представления модели (MVC) проект, это действительно не. Компоненты Swing обычно реализуются так, чтобы представление и контроллер были неделимы, реализованы единственным объектом UI, обеспеченным стилем. Архитектура модели Swing более точно описывается как отделимая архитектура модели. Если Вы интересуетесь узнаванием больше об архитектуре модели Swing, см. Краткий обзор Архитектуры Swing, статью в Соединении Swing.

Пример: Преобразователь

Этот раздел обладает примером под названием Преобразователь, который является приложением, которое непрерывно преобразовывает измерения расстояния между метрическими и американскими модулями. Можно работать, Преобразователь (загрузите JDK 6 или позже). Или, чтобы скомпилировать и выполнить пример самостоятельно, консультируйтесь, пример индексируют.

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

Важная вещь для этой программы гарантирует, что только одна модель управляет значением данных. Есть различные способы достигнуть этого; мы сделали это, подчиняясь модели главного ползунка. Нижняя модель ползунка (экземпляр пользовательского class вызывают FollowerRangeModel) вперед все данные запрашивают к модели главного ползунка (экземпляр пользовательского вызванного class ConverterRangeModel). Каждое текстовое поле сохраняется в синхронизации с его ползунком, и наоборот, обработчиками событий, которые прислушиваются к изменениям в значении. Забота проявляется, чтобы гарантировать, что модель главного ползунка имеет последнее слово о том, какое расстояние выводится на экран.

Когда мы начинали реализовывать пользовательские модели ползунка, мы сначала смотрели на раздел API того, Как Использовать Ползунки. Это сообщало нам, что все модели данных ползунка должны реализовать BoundedRangeModel интерфейс. BoundedRangeModel Документация API говорит нам, что интерфейсу назвали реализацию class DefaultBoundedRangeModel. Документация API для DefaultBoundedRangeModel шоу, из которых это является реализация общего назначения BoundedRangeModel.

Мы не использовали DefaultBoundedRangeModel непосредственно, потому что это хранит данные как целые числа, и Преобразователь использует данные с плавающей точкой. Таким образом мы реализовывали ConverterRangeModel как подкласс Object. Мы тогда реализовывали FollowerRangeModel как подкласс ConverterRangeModel.

Для Дополнительной информации

Чтобы узнать о моделях для отдельных компонентов, см. "Как к" страницам и документации API для отдельных компонентов. Вот некоторые из наших примеров, которые используют модели непосредственно:

• Все кроме самого простого из табличных примеров реализуют пользовательские табличные модели данных.
• У цветных демонстрационных примеров селектора есть слушатели изменения на модели выбора цветного селектора, таким образом, они могут быть уведомлены, когда пользователь выбирает новый цвет. В ColorChooserDemo2, CrayonPanel class непосредственно использует цветную модель выбора, чтобы выбрать текущий цвет.
• Пример DynamicTreeDemo устанавливает древовидную модель (к экземпляру DefaultTreeModel), взаимодействует непосредственно с этим, и прислушивается к изменениям к этому.
• ListDemo устанавливает модель данных списка (к экземпляру DefaultListModel) и взаимодействует непосредственно с этим.
• SharedModelDemo определяет a SharedDataModel class, который расширяется DefaultListModel и реализации TableModel. A JList и JTable совместно используйте экземпляр SharedDataModel, обеспечение других представлений данных модели.
• В конечном счете примеры слушателя, ListDataEventDemo создает и использует a DefaultListModel непосредственно.
• Наши примеры прядильщика создают модели прядильщика.
• Как Вы уже видели, пример Преобразователя определяет две пользовательских модели ползунка.