Графические интерфейсы пользователя Java - Тимур Сергеевич Машнин Страница 13

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

Архитектура Model-View-Controller

Теперь, когда мы уже рассмотрели ряд Swing компонентов, давайте вернемся к архитектуре model-view-controller (MVC).

MVC – это общий подход к построению графических приложений.

Суть идеи заключается в том, чтобы низлежащие данные, отображение и логика, которая контролирует данные и отображение, должны быть развязаны.

Эта идея исходит из того, что мы хотели бы иметь более одного способа посмотреть на одни и те же данные.

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

Еще один пример из реляционных баз данных.

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

Поэтому архитектура MVC предлагает нам строить графические интерфейсы с помощью моделей, видов и контроллеров.

Модель является источником данных, а вид – это Представление данных.

Модель ничего не знает вообще о Представлениях.

Однако, если Модель является динамичной, тогда она обеспечивает интерфейс прослушивания.

Таким образом, Представление является просто наблюдателем модели.

Когда данные в Модели меняются, она генерирует событие, отражающее изменение.

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

Хорошо, где Контроллер в этой картине?

Контролер отвечает за изменение модели.

С помощью Контроллера, мы можем изменить то, как компонент отвечает на запросы пользователя без изменения его визуального представления.

Обычно Контроллер состоит из графической части и некоторой логики приложения.

Например, вы хотите добавить меню в свой редактор.

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

Теперь, добавляя меню, вы делаете его частью своего контроллера.

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

Контроллер – это способ, которым пользователь меняет модель.

Контроллер не обновляет Представление, потому что оно автоматически получает обновления, как наблюдатель модели.

Давайте теперь посмотрим на пример MVC.

Рассмотрим модель SimpleStringModel, которая будет иметь один контроллер и несколько видов.

В этой модели у нас есть два метода getString и setString.

В методе setString мы устанавливаем новое значение поля класса и уведомляем всех слушателей модели, вызывая метод интерфейса, который эти слушатели реализуют.

Соответственно объект модели хранит список своих слушателей.

Представление здесь – это компонент, расширяющий метку.

Представление имеет метод setModel, в котором Представление становится слушателем Модели.

При изменении модели, автоматически вызывается метод setText метки, который изменяет надпись метки.

Контроллер здесь текстовое поле, в которое пользователь вводит строку текста, и эта строка становится новым значением Модели.

Этот базовый пример иллюстрирует, как реализуется архитектура MVC.

Еще одна интересная и очень полезная функция, которую мы получаем, когда используем MVC.

Предположим, что допустимы не все значения, которые пользователь может ввести в текстовое поле.

Путем выброса исключения в методе set модели мы можем запретить изменение представления.

Swing реализация MVC объединяет Controller и View представление.

На самом деле это не очень сложно сделать.

Вы просто размещаете функции View представления и Сontroller в одном классе.

В предыдущем примере у нас было два графических компонента – один для Представления, а второй для Контоллера.

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

При этом этот же компонент становится слушателем модели, перерисовывая себя при изменении модели.

Давайте посмотрим, как реализована архитектура MVC в Swing на примере списка.

Давайте посмотрим на интерфейс ListModel, представляющий модель данных списка.

Во-первых, этот интерфейс легковесный, так как в нем нет ссылки на сам список.

Во-вторых, этот интерфейс присоединяет слушателя модели, как задумано в MVC.

И есть способ получения данных модели, с помощью методов size/get, что гораздо лучше, чем использование метода, например, возвращающего массив данных, так как при использовании методов size/get не занимается память под массив данных, не происходит копирование данных.

Давайте посмотрим на этот пример модели списка, в которой низлежащие данные изменяются динамически.

Часто бывает, что данные, которые предоставляются пользователю, меняются, и экран необходимо обновлять.

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

Таким образом, списки просто перерисовываются, чтобы отражать изменения.

В этом примере у нас есть список, который отображает список случайно генерируемых целых чисел.

Теперь, еще одной очень полезной концепцией является отфильтрованная модель.

Часто бывает так, что мы хотим создать представление, содержащее только подмножество данных.

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

Таким образом, происходит фильтрация данных модели.

Еще одна полезная концепция – это слияние моделей.

В этом случае есть модель, которая принимает две модели в качестве аргумента и представляет их как одну.

Опять же это делается с помощью методов size/get без копирования данных исходных моделей.

Таким образом, есть много интересных вещей, которые мы можем делать с моделями.

Помимо отдельного класса модели, некоторые Swing компоненты также используют отдельный класс для рендеринга и просмотра.

Например, JList позволяет пользователю определить ListCellRenderer, который является небольшим классом, который заботится о том, как конкретный элемент списка будет визуализирован.

Этот интерфейс имеет только один метод getListCellRendererComponent.

Каждый раз, когда список себя перерисовывает, он запрашивает средство визуализации ячейки ListCellRenderer.

Это полезно по нескольким причинам.

Во-первых, обычно данные, которые вы хотите отобразить в списке, не хранятся в виде строк.

И список не знает, как отобразить произвольный объект как String.

Вы можете думать о СellRenderer как об адаптере, который знает, как адаптировать объект к строке.

Как вы видите в этом примере, фактический список содержит учеников, а не строки, которые отображаются.

Предположим, мы используем этот список, чтобы пользователи могли выбирать в нем студентов.

Это означает, что, когда пользователь выбирает строку на экране, тогда выбранное значение списка фактически должно быть объектом Student, а не строкой.

Для этого все, что нам нужно сделать, это написать адаптер ListModel, который переводит интерфейс ListModel в интерфейс реального источника данных.

Здесь реальный источник данных – это список java.util.List.

И этот адаптер использует этот список в своих методах size/get.

Здесь видно, что не происходит дублирование данных, и мы работаем с реальными объектами, а не с некоторыми их строковыми представлениями.

Еще одно преимущество, которое мы получаем от использования