Материал: Портянкин И. Swing

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

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

Надо сказать, что разделение функций компонента только на две части (UI-представи- теля и модель) как нельзя лучше подходит для Swing. Разработчики Swing не стремились создать какой-то новый тип пользовательского интерфейса, они, прежде всего, должны были обеспечить поддержку компонентами всех известных платформ таким образом, чтобы Java-приложения по возможности внешне не отличались от приложения для конкретной платформы. UI-представители позволяют легко реализовать такое поведение. Оставляя функции компонента и модели данных в стороне, нужно лишь изменить UIпредставителя, чтобы он реагировал на действия, характерные для какой-то платформы,

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

создатели Swing сумели сохранить ее основные достоинства: простое изменение внешнего вида и поведения компонентов (это осуществляется заменой UI-представителя компонента), а также мощь модельного программирования (программист по-прежнему может использовать различные модели для одного компонента, менять данные и манипулировать ими, не заботясь об обновлении вида и о типе компонента, описывать данные в терминах решаемой задачи). Не совсем правильно говорить, что в Swing задействована архитектура MVC (в библиотеке реализована архитектура из двух частей, а не из трех), поэтому часто говорят об использовании в Swing отношения модель-представитель (modeldelegate), или об архитектуре с разделенной моделью (separable model architecture).

Как все работает

Кажется, мы дошли до сути механизма, обеспечивающего компонентам Swing различные поведение и внешний вид. Имеется UI-представитель, обрабатывающий события пользователя и рисующий компонент на экране; есть модель, хранящая данные компонента. Непонятно одно — как этот механизм взаимодействует с классами библиотеки Swing, такими как кнопки (JButton) или списки (JList). Работать с ними просто — вы создаете экземпляр класса кнопки и добавляете его в контейнер. Где же UI-представитель? Очевидно, что не в классах компонентов, иначе менять их внешний вид и поведение было бы невозможно (пришлось бы переписывать все эти классы для поддержки другого внешнего вида).

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

ссылка. Хранится эта ссылка в классе компонента. UI-представитель связывается с моделью только через класс компонента. Прямой связи нет, и это главное условие гибкости и взаимозаменяемости. Таким образом осуществляется обмен данными между видом и моделью. Программисту, намеревающемуся использовать некоторый компонент, не придется думать о том, какой UI-представитель задействован в данный момент и как его соединить с моделью. От него требуется лишь настроить модель (или применить модель по умолчанию) и передать ее компоненту. Компонент знает, какого UI-предста- вителя нужно использовать (он получает эту информацию от менеджера внешнего вида UIManager, о котором мы вскоре поговорим), и готов к работе10.

Рис. 1.5. Взаимоотношения UI-представителя и модели

Следует четко осознать, что именно классы компонентов (такие как JButton и JTable) являются основной частью библиотеки Swing. Может показаться, что они не так уж важны: ведь в них не происходит ни прорисовка компонента, ни обработка событий, ни манипуляция данными. Однако это не так: UI-представители и модели являются лишь частью внутреннего механизма библиотеки, а сами они не представляют большого интереса. Компонент просто делегирует к ним запросы: представитель осуществляет прорисовку и обработку событий, а модель хранит данные. Как мы уже выяснили, это обеспечивает великолепную гибкость библиотеки. Главными остаются компоненты Swing — все свойства (название кнопки, данные таблицы и т. п.) принадлежат им, они являются компонентами JavaBeans, ими вы манипулируете в своей программе или в визуальном средстве, именно они получают события от операционной системы и ресурсы для прорисовки, которые затем передают для выполнения действий в UI-представителей.

Управление внешним видом и поведением программы

В библиотеке Swing довольно много компонентов, и каждый из них имеет своего UI-представителя, ответственного за обработку событий и прорисовку компонента на экране. Рано или поздно настает момент, когда внешний вид и поведение вашего Javaприложения приходится менять (например, чтобы оно выглядело одинаково с приложениями той платформы, на которой ему приходиться работать). Если бы разработчику

10 Если использовать терминологию шаблонов проектирования, то можно сказать, что с точки зрения UI-представителей и моделей классы компонентов Swing действуют как посредники (mediators), обеспечивая слабую связанность системы. С точки же зрения программистов-клиентов Swing классы компонентов являются фасадами (facade) для архитектуры «модель-представитель» (применяя компонент, не обязательно задумываться о том, что происходит внутри него).

сможете перенести его на Unix, потому что использовать внешний вид Windows на других платформах запрещено (а рекомендации Microsoft для интерфейса Unix не подходят, и это еще мягко сказано). Разрабатывая приложение под Mac, вы будете следовать рекомендациям Apple, и, сменив внешний вид приложения, можете сильно удивиться результатам.

Здесь на передний план выходит независимый от платформы внешний вид, Nimbus или Metal, специально созданный для Java-приложений. Компания Sun разработала для него ряд рекомендаций, выполняя которые, можно получить по-настоящему красивые интерфейсы. Мы подробно рассмотрим эти рекомендации и этапы воплощения их в жизнь в главе 7, когда будем говорить о размещении компонентов в контейнере. Создав интерфейс специально для независимого внешнего вида, вы с легкостью перенесете его на любую платформу. Все сказанное не стоит воспринимать как совет отказаться от внешних видов, эмулирующих известные платформы, но, как показывает практика, их использование все равно не обеспечивает полного соответствия «родным» приложениям этих платформ. Дело в том, что Swing всегда находится на шаг позади (сначала меняется интерфейс конкретной платформы, команда Swing разрабатывает внешний вид, эмулирующий этот интерфейс, обновленный внешний вид выходит в новом пакете JDK, а в это время интерфейс конкретной платформы опять меняется, пусть даже и ненамного). За изменения же внешнего вида Java можно не беспокоиться, потому что он меняется одновременно со Swing.

Некоторые вопросы вызывает внешний вид компонентов в стиле Nimbus и особенно Metal. Многие, мягко говоря, не находят их привлекательными (следует признать, что причины для недовольства имеются — слишком уж «топорно» выглядит этот лаконичный интерфейс по сравнению с современными системами пользовательских интерфейсов). Но вы вовсе не ограничены внешними видами, созданными в Sun. На данный момент имеется умопомрачительное количество разнообразных внешних видов, некоторые их которых определенно стоят того, чтобы на них обратили внимание. Вы вполне можете задействовать вместо него один из интерфейсов от стороннего производителя, по-прежнему выполняя рекомендации для интерфейсов от Sun, потому что большинство сторонних внешних видов являются просто производными от Metal/Synth/ Nimbus, оставляя без изменения поведение, размеры компонентов и пр. и меняя лишь изображения. Для начала можно зайти на сайт http://www.javootoo.com/, где найдутся все наиболее популярные внешние виды для Swing, например очень популярный и используемый во многих коммерческих продуктах с применением Swing внешний вид JGoodies Looks (при использовании в интерфейсе рекомендаций для внешнего вида Metal и компонентов во внешнем виде JGoodies Looks получаются приложения, способные «обставить» самые продуманные и изысканные пользовательские интерфейсы). В качестве неплохой и бесплатной замены внешнему виду Metal/Nimbus хорошо подходит внешний вид Substance, Liquid и многие другие.

С другой стороны, новый внешний вид Nimbus, который возможно станет внешним видом по умолчанию в версии JDK 1.7, намного приятнее и современнее своего предшественника Metal. Его цветовая гамма очевидно стремится к Unix, однако, как легко узнать из его документации, цвета Nimbus легко меняются несколькими настройками (управляют основными эффектами три базовых цвета), а тот факт, что Nimbus построен на Synth, позволяет подменять изображения, цвета или процедуру прорисовки любого компонента. Это может помочь создать намного более приятный внешний вид, чем тот, что доступен по умолчанию, с достаточно маленькими затратами.

Но в целом, подключаемые внешний вид и поведение (Pluggable Look And Feel, PLAF) — одно из самых мощных свойств Swing. Никакая другая библиотека или операционная система не позволяет осуществить подобные масштабные действия настолько просто и быстро. Вы можете разработать для своего приложения любой вид, не задумываясь о платформах и их различиях, создать совершенно особый колорит, подчерки-