Визуальное программирование и компоненты (Beans)
Далее в этой книге вы увидите, как ценен Java для создания кусочков кода для повторного использования. “Наиболее часто используемый” блок кода имеет класс, так как он включает связующий модуль характеристик (полей) и поведений (методов), которые могут быть повторно использованы либо напрямую через композицию, либо через наследование.
Наследование и полиморфизм - это главные части объектно-ориентированного программирования, но для большинства классов, когда вы помещаете их вместе в приложение, то, что вы хотите - это то, чтобы компоненты точно делали то, что вам нужно. Вы можете ввести эти части в вашу разработку, как инженер-электронщик помещает вместе микросхемы на плате. Кажется, что должен быть способ для ускорения такого стиля программирования “модульной сборки”.
Первый успешный опыт “визуального программирования” — очень успешный — был получен с Visual Basic (VB) фирмы Microsoft, далее, среда второго поколения - это Delphi от Borland (главный вдохновитель дизайна JavaBeans). С этими инструментами программирования компоненты представлялись визуально, как кнопки или текстовые поля. Визуальное представление, фактически, часто является точным способом показа компонента в работающей программе. Так что часть процесса визуального программирования затрагивает перетаскивание компонент из палитры и помещение их в вашу форму. Инструмент построения приложения пишет код за вас, и этот код является причиной создания компонент в работающей программе.
Простого помещения компонент в форму обычно не достаточно для компиляции программ. Часто вы должны изменить характеристики компонент, такие как цвет, внутренний текст, присоединенную базу данных и т.п. Характеристики, которые могут быть изменены во время дизайна, называются свойствами (properties). Вы можете манипулировать свойствами вашего компонента внутри построителя приложения, и когда вы создадите программу, эти конфигурационные данные будут сохранены, так что они могут быть обновлены при запуске программы.
Теперь вы, вероятно, используете идею, что объект - это больше, чем характеристики; это также набор поведений. Во время дизайна, поведение визуальных компонент частично представлено событиями (events), означающих “Здесь то, что может случиться с компонентом”. Обычно вы решаете, что вам нужно при возникновении события, печатая код этого события.
Здесь заключена критическая часть: построитель приложения использует рефлексию для динамического исследования компоненты для нахождения свойств, чтобы позволить вам изменить их (записать состояние при построении программы), а также для отображения событий. В общем, вы делаете что-то типа двойного щелчка на событии, и построитель приложения создает тело кода и привязывает его к определенному событию. Все, что вы делаете в этом месте, это пишите код, выполняющийся при возникновении события.
Все это прибавляет работы, которую выполняет за вас построитель приложения. В результате вы можете сфокусировать внимание на том, как программа должна выглядеть, и для чего она предназначена, и положится на построитель приложения в управлении деталями. По этой причине инструменты визуального программирования так успешно применяются, они значительно ускоряют процесс построения приложения — в основном интерфейса пользователя, но часто и других частей приложения.
