13.1 Почему использовать AWT?

Для "старого" AWT, который мы будем изучать в этой главе, самым серьезным недостатком является то, что он имеет недостаточное качество как с точки зрения объектно-ориентированного дизайна, так и с точки зрения дизайна библиотек для создания графического интерфейса пользователя (GUI). Это заставляет нас вернуться в темные времена программирования (что можно выразить как "плохо", "ужасно", "недопустимо" и т. д.). Приходится писать код для выполнения каждого события, включая задачи, которые легко выполняются с использованием "ресурсов" в других окружениях.

Многие такие проблемы были частично решены или полностью устранены в Java 1.1, поскольку:

(1) Новый AWT в Java 1.1 представляет собой лучшую модель программирования и шаг вперед к более качественной библиотеке. Java Beans представляют собой архитектуру для этой библиотеки.

(2) "Конструктор GUI" (внешняя среда для визуального программирования) будет применим ко всем системам разработки. Когда мы используем графический инструмент для помещения компонентов в окно, Java Beans и новый AWT позволяют конструктору GUI автоматически генерировать код. Другие технологии компонентов, такие как ActiveX, также будут поддерживаться таким же образом.Итак, почему нам всё ещё приходится учиться использовать старый AWT? Ответ прост — потому что он существует. В настоящее время это может быть неблагоприятной ситуацией для нас, но она связана с принципами объектно-ориентированного проектирования библиотек: если мы объявили компонент в нашей библиотеке, мы больше не можем его удалить. Удаление такого компонента повредит существующий код других людей. Кроме того, когда мы изучаем Java и все программы, использующие старый AWT, мы видим, что многие из этих программ используют старый AWT.AWT должна иметь возможность взаимодействовать с компонентами графического интерфейса операционной системы, что означает необходимость выполнения задач, которые невозможно выполнить для непроверенного апплета. Непроверенный апплет не может выполнять прямые вызовы в операционной системе, поскольку это могло бы привести к неконтролируемым действиям на компьютере пользователя. Непроверенный апплет не имеет доступа к важным функциям. Например, единственный способ нарисовать окно на экране — это через вызов специальной библиотеки Java с особым интерфейсом и проверками безопасности. Оригинальная модель доверия Sun создала доверенные библиотеки, которые могут использоваться только для автоматической авторизации Java системы в веб-браузерах, где контроллер управляет доступом к библиотекам. Однако, что делать, если мы хотим расширить возможности доступа к новым компонентам в операционной системе? Ждать, пока Sun примет решение о нашем расширении, которое будет включено в стандартную библиотеку Java, но это может не решить наши проблемы. Новая модель в версии Java 1.1 — "доверенный код" или "подписанный код", поэтому специальный сервер проверяет код, который мы загружаем с использованием открытого ключа системы шифрования, установленной конкретным разработчиком.Таким образом, мы можем узнать, откуда взят этот код, действительно ли это код Боба, а не какой-то другой человек, выдающий себя за Боба. Это не предотвратит ошибки или злонамеренные действия со стороны Боба, но поможет предотвратить ситуацию, когда Боб пытается избежать ответственности за создание компьютерных вирусов анонимно. Цифровой подписью программы — "доверием к программе" — программа в версии Java 1.1 получает возможность войти в нашу машину и непосредственно контролировать её, как некоторые другие приложения автоматически получают "доверие" и устанавливаются на нашей машине. Это все особенности старого AWT. Код старого AWT будет продолжать существовать, и новые Java-разработчики столкнутся с ним при изучении старых учебников. Также стоит изучить старый AWT, например, в контексте проектирования программ с ограниченным количеством библиотек. Область применения старого AWT представлена без углубления в детали и полного перечня всех программ и классов, а лишь даёт общее представление о дизайне старого AWT.