Философия Java


Визуальное программирование и компоненты (Beans)


Далее в этой книге вы увидите, как ценен Java для создания кусочков кода для повторного использования. “Наиболее часто используемый” блок кода имеет класс, так как он включает связующий модуль характеристик (полей) и поведений (методов), которые могут быть повторно использованы либо напрямую через композицию, либо через наследование.

Наследование и полиморфизм - это главные части объектно-ориентированного программирования, но для большинства классов, когда вы помещаете их вместе в приложение, то, что вы хотите - это то, чтобы компоненты точно делали то, что вам нужно. Вы можете ввести эти части в вашу разработку, как инженер-электронщик помещает вместе микросхемы на плате. Кажется, что должен быть способ для ускорения такого стиля программирования “модульной сборки”.

Первый успешный опыт “визуального программирования” — очень успешный — был получен с Visual Basic (VB) фирмы Microsoft, далее, среда второго поколения - это Delphi от Borland (главный вдохновитель дизайна JavaBeans). С этими инструментами программирования компоненты представлялись визуально, как кнопки или текстовые поля. Визуальное представление, фактически, часто является точным способом показа компонента в работающей программе. Так что часть процесса визуального программирования затрагивает перетаскивание компонент из палитры и помещение их в вашу форму. Инструмент построения приложения пишет код за вас, и этот код является причиной создания компонент в работающей программе.

Простого помещения компонент в форму обычно не достаточно для компиляции программ. Часто вы должны изменить характеристики компонент, такие как цвет, внутренний текст, присоединенную базу данных и т.п. Характеристики, которые могут быть изменены во время дизайна, называются свойствами (properties). Вы можете манипулировать свойствами вашего компонента внутри построителя приложения, и когда вы создадите программу, эти конфигурационные данные будут сохранены, так что они могут быть обновлены при запуске программы.

Теперь вы, вероятно, используете идею, что объект - это больше, чем характеристики; это также набор поведений. Во время дизайна, поведение визуальных компонент частично представлено событиями (events), означающих “Здесь то, что может случиться с компонентом”. Обычно вы решаете, что вам нужно при возникновении события, печатая код этого события.




Начало  Назад  Вперед



Книжный магазин