Java 7

ЧАСТЬ III Создание графического интерфейса пользователя и апплетов

Глава 8.	Принципы построения графического интерфейса
Глава 9.	Графические примитивы
Глава 10.	Основные компоненты AWT
Глава 11.	Оформление ГИП компонентами Swing
Глава 12.	Текстовые компоненты
Глава 13.	Таблицы
Глава 14.	Размещение компонентов и контейнеры Swing
Глава 15.	Обработка событий
Глава 16.	Оформление рамок
Глава 17.	Изменение внешнего вида компонента
Глава 18.	Апплеты
Глава 19.	Прочие свойства Swing
Глава 20.	Изображения и звук

ГЛАВА 8

Принципы построения графического интерфейса

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

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

За десятилетия развития вычислительной техники создано много различных графических систем: MS Windows, X Window System, Macintosh. В каждой из них свои правила построения окон и их компонентов: меню, полей ввода, кнопок, списков, полос прокрутки. Эти правила сложны и запутаны. Графические API, предназначенные для создания пользовательского интерфейса, содержат сотни функций.

Для облегчения создания окон и их компонентов написаны библиотеки функций и классов: MFC, Motif, OpenLook, Qt, Tk, Xview, OpenWindows, OpenGL, GTK+ и множество других. Каждый класс такой библиотеки описывает сразу целый графический компонент, управляемый методами этого и других классов.

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

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

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

Такие интерфейсы были названы peer-интерфейсами.

Библиотека классов Java, основанных на peer-интерфейсах, получила название AWT (Abstract Window Toolkit). Для вывода на экран объекта, созданного в приложении Java и основанного на peer-интерфейсе, создается парный ему (peer-to-peer) объект графической подсистемы операционной системы, который и отображается на экране. Поэтому графические объекты AWT в каждой графической среде имеют вид, характерный для этой среды: в MS Windows, Motif, OpenLook, OpenWindows, — везде окна, созданные в AWT, выглядят как "родные" окна этой графической среды.

Пара объектов, реализующих один peer-интерфейс, тесно взаимодействуют во время работы приложения. Изменение объекта в приложении Java немедленно влечет изменение объекта графической оболочки и меняет его вид на экране.

Именно из-за такой реализации peer-интерфейсов и других "родных" (native) методов, написанных главным образом на языке С++, приходится для каждой платформы выпускать свой вариант JDK.

В версии JDK 1.1 библиотека AWT была переработана. В нее добавлена возможность создания компонентов, полностью написанных на Java и не зависящих от peer-интерфейсов. Такие компоненты стали называть "легкими" (lightweight), в отличие от компонентов, реализованных через peer-интерфейсы, названных "тяжелыми" (heavy).