Графические интерфейсы пользователя Java

Java 1.1 реализует модель делегирования, в которой события передаются только объектам, зарегистрированным для получения события.

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

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

В модели событий Java 1.1 вся функциональность обработки событий содержится в пакете java.awt. event.

Внутри этого пакета подклассы абстрактного класса AWTEvent представляют собой различные виды событий.

Класс AWTEvent и его подклассы заменяют Event предыдущей модели событий.

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

Эти интерфейсы определяют методы, вызываемые при возникновении событий соответствующего типа.

Пакет также содержит ряд классов адаптеров.

Они реализуют интерфейсы EventListener и являются абстрактными классами, которые предоставляют нулевые реализации методов соответствующего прослушивателя.

Эти классы удобны для создания объектов-слушателей.

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

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

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

Эта модель называется «делегирование».

Она реализует шаблон проектирования Observer.

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

Важно, чтобы любой объект, а не только компонент, мог получать события.

Таким образом, вы можете отделить свой код обработки событий от вашего графического интерфейса.

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

Это означает, что, если вы разработали хороший интерфейс, вы можете повторно использовать его в разных приложениях, изменив обработку событий.

Модель делегирования важна для JavaBeans, которые позволяют взаимодействовать между Java и другими платформами.

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

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

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

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

В Java 1.1 это не требуется.

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

Наконец, эта модель событий представляет идею очереди событий.

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

В Java 1.1 каждый компонент является источником события, который может генерировать определенные типы событий, которые являются подклассами класса AWTEvent.

Объекты, которые интересуются событием, называются слушателями.

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

Чтобы получить событие, объект должен реализовать соответствующий интерфейс слушателя и должен быть зарегистрирован в источнике события, путем вызова метода «add listener» компонента, который генерирует событие.

И мы это уже видели.

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

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

Как только объект зарегистрирован, метод actionPerformed будет вызываться всякий раз, когда пользователь делает что-либо в компоненте, который генерирует событие действия.

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

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

Некоторые интерфейсы слушателей предназначены для работы с несколькими типами событий.

Например, интерфейс MouseListener объявляет пять методов обработки различных типов событий мыши: мышь вниз, мышь вверх, щелчок, вход мыши в компонент и выход мыши.

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

Это звучит как создание излишнего кода; большую часть времени вас интересует только одно или два из этих событий.

К счастью, вам этого делать не нужно.

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

И если вы хотите написать класс обработки событий, который имеет дело только с щелчками мыши, вы можете объявить, что ваш класс расширяет MouseAdapter.

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

Таким образом, резюмируя.

Компоненты генерируют AWTEvents, когда что-то происходит.