- •1. Общие характеристики
- •1.1 Основные характеристики
- •1.1.1 Скорость визуальной разработки
- •1.1.2 Продуктивность компонент
- •1.1.4 Масштабируемые соединения с базами данных
- •1.2 Другие программные продукты Borland
- •1.3 Проблемы совместимости
- •1.3.2.1 Какую систему выбрать?
- •1.3.2.2 Какая система является более мошной?
- •2.1 Первое знакомство
- •2.1.1 Визуальное проектирование
- •2.1 Первое знакомство
- •2.1.2 Свойства, методы и события
- •2.1.3 Технология двунаправленной разработки
- •2.1.4 Использование проектных шаблонов
- •2.2 Палитра компонент - краткий обзор
- •2.3 Приложения управления базами данных
- •2.3.1 Пример из существующего проекта
- •2.4 Итоги
- •3.1 Инкапсуляция
- •3.2 Классы, компоненты и объекты
- •3.3 Наследование
- •3.5 Полиморфизм
- •3.5.2 Дружественные функции
- •3.6.1.1 Объявления компонентных классов
- •3.6.1.2 Объявления свойств
- •3.6.1.3 Объявления обработчиков событий '
- •3.6.1.4 Объявления автоматизированных свойств и методов
- •3.6.1.5 Быстрый вызов функций
- •3.6.1.6 Расширенные типы данных Delphi
- •3.6.2.1 Шаблоны
- •3.6.2.2 Пространства имен
- •3.6.2.3 Явные объявления
- •3.6.2.4 Непостоянные объявления
- •3.6.2.5 Идентификация типов rtti
- •3.6.2.6 Исключения
- •4. Инструменты визуальной разработки приложений
- •4.1 Администратор проекта
- •4.2 Редактор форм
- •4.3 Инспектор объектов
- •4.4 Хранилище объектов
- •4.4.1 Разделение объектов
- •4.5 Редактор кода
- •4.6 Палитра компонент
- •4.6.1.2 TPopUpMenu
- •4.6.1.4 TEdit
- •4.6.1.6 TButton
- •4.6.1.7 TCheckBox
- •4.6.1.8 Ей tRadioButton
- •4.6.1.9 TListBox
- •4.6.1.10 TComboBox
- •4.6.1.12 TGroupВох
- •4.6.2.1 TTabControl
- •4.6.2.2 TPageControl
- •4.6.2.5 TImageList
- •4.6.2.6 THeaderControl
- •4.6.2.7 TRichEdit
- •4.6.2.9 TTrackBar
- •4.6.2.10 TProgressBar
- •4.6.2.11 TUpDown
- •4.6.2.12 И tHotKey
- •4.6.3.5 TDrawGrid
- •4.6.4.1 TDataSource
- •4.6.4.2 ТТаble
- •4.6.4.3 TQuery
- •4.6.4.4 TStoredProc
- •4.6.4.6 TSession
- •4.6.4.8 TUpdateSql
- •4.6.5.1 TdbGrid
- •4.6.5.2 TdbNavigator
- •4.6.5.3 TdbText
- •4.6.5.4 TdbEdit
- •4.6.5.6 TdbImage
- •4.6.5.7 TdbListBox
- •4.6.5.8 TdbComboBox
- •4.6.5.9 TdbCheckBox
- •4.6.5.11 TdbLookupListBox
- •4.6.7.1 TOpenDialog
- •4.6.7.2 TSaveDialog
- •4.6.7.3 TFontDialog
- •4.6.7.4 TColorDialog
- •4.6.7.5 TPrintDialog
- •4.6.7.6 TPrinterSetupDialog
- •4.6.7.8 TReplaceDialog
- •4.6.7.9 Использование диалоговых компонент текстовым редактором. Приемы отладки
- •4.6.8.1 TTimer
- •4.6.8.2 TPaintBox
- •4.6.8.3 TFileListBox
- •4.6.8.6 TFilterComboBox
- •4.6.8.7 TMediaPlayer
- •4.6.8.8 TOleContainer
- •4.6.8.9 TDdeClientConv
- •4.6.8.10 TDdeClientltem
- •4.6.8.11 TDdeServerConv
- •4.6.8.12 TDdeServerltem
- •4.6.9.1 TQuickReport
- •4.6.9.2 TqrBand
- •4.7 Дизайнер меню
- •4.8 Итоги
- •5. Визуальная разработка приложений баз данных
- •5.1 Организация доступа к базам данных
- •5.1.2.1 Страница Drivers
- •5.1.2.2 Страница Aliases
- •5.1.2.3 Страница System
- •5.1.2.4 Страница Date
- •5 .1.2.5 Страница Time
- •5.1.2.6 Страница Number
- •5*2 Использование визуальных компонент
- •5.2.1.1 Источники данных
- •6. Использование и создание визуальных компонент
- •6.1 Назначение и устройство vcl
- •6.2 Типы компонент
- •6.2.5.1 Право владения
- •6.2.5.2 Родительское право
- •6.2.5.3 Поточность
- •6.3 Свойства компонент
- •6.3.1 Зачем нужны свойства?
- •6.3.2.1 Доступ к внутренним данным свойств
- •6.3.2.2 Свойства обеспечивают доступ к членам данных
- •6.3.2.3 Методы записи и чтения свойств
- •6.3.3 Переопределение свойств
- •6.3.4.1 Свойства типа множество
- •6.3.4.2 Свойства типа массив
- •6.4 События
- •6.4.1 Зачем нужны события?
- •6.4.2 Определение событий
- •6.4.2.3 Стандартные события
- •6.4.2.4 Собственные события
- •6.4.2.5 События и сообщения Windows
- •6.4.3 Обработка событий
- •6.5 Методы
- •6.5.1 Вызовы статических методов
- •6.6.1 TObject
- •6.6.2 TPersistent
- •6.6.3 TComponent
- •6.6.4 TControl
- •6.6.5 TWinControl
- •6.6.6 TGraphicControl
- •6.7 Схема разработки компонент
- •6.7.1 Создание модуля компоненты
- •6.7.2 Наследование компоненты
- •6.7.2.1 Модификация существующих компонент
- •6.7.2.2 Создание оригинальных оконных компонент
- •6.7.2.3 Создание графических компонент
- •6.7.2.4 Создание невидимых компонент
- •6.7.3 Добавление свойств, событий и методов.
- •6.7.4 Регистрация компоненты
- •6.7.5 Отладка неинсталлированной компоненты
- •6.7.6 Инсталляция компоненты на Палитру
- •6.7.7 Сохранение файлов новой компоненты
- •6.8 Разработка простой компоненты
- •6.8.1 Форма тестового приложения
- •6.8.2 Модуль тестового приложения
- •6.8.3 Члены данных, свойства и методы
- •6.8.4 Испытание компоненты
- •6.8.5 Инсталляция компоненты
- •6.9 Итоги
- •7. Графические компоненты
- •7*2 Использование канвы
- •7.3 Работа с рисунками
- •7.3.1 Рисунок, графика или канва9
- •7.3.2 Графические файлы
- •7.3.3 Обслуживание палитр
- •7.4 Внеэкранные битовые образы
- •7.4.1 Копирование битовых образов.
- •7.4.2 Создание и обслуживание
- •7.4.3 Реакция на изменения
- •7.5 Разработка графического приложения
- •7.5.1 Проектирование формы
- •7.5.2 Программный модуль
3.5 Полиморфизм
Слово полшюрфизм от греческих слов poly (много) и morphos (форма) означает множественность форм. Полиморфизм - это свойство родственных объектов (т.е. объектов, классы которых являются производными от одного родителя) вести себя по-разному в зависимости от ситуации, возникающей в момент выполнения программы. В рамках ООП программист может влиять на поведение объекта только косвенно, изменяя входящие в него методы и придавая потомкам отсутствующие у родителя специфические свойства.
Для изменения метода необходимо перегрузить его в потомке, т.е. объявить в потомке одноименный метод и реализовать в нем нужные действия. В результате в объекте-родителе и объекте-потомке будут действовать два одноименных метода, имеющие разную кодовую реализацию и, следовательно, придающие объектам разное поведение. Например, в иерархии родственных классов геометрических фигур (точка, прямая линия, квадрат, прямоугольник, окружность, эллипс и т.д.) каждый класс имеет метод Draw, который отвечает за надлежащий отклик на событие с требованием нарисовать эту фигуру.
Благодаря полиморфизму, потомки могут перегружать общие методы родителя с тем, чтобы реагировать специфическим образом на одно и то же событие.
3.5.1 Виртуальные функции
В ООП полиморфизм достигается не только описанным выше механизмом наследования и перегрузки методов родителя, но и виртуализацией, позволяющей родительским функциям обращаться к функциям потомков. Полиморфизм реализуется через архитектуру класса, но полиморфными могут быть только функции-члены.
В C++ полиморфная функция привязывается к одной из возможных одноименных функций только в момент исполнения, когда ей передается конкретный объект класса. Другими словами, вызов функции в исходном тексте программы лишь обозначается, без точного указания на то, какая именно функция вызывается. Такой процесс известен как позднее связывание. Листинг 3.9 показывает, к чему может привести не полиморфное поведение обычных функций-членов.
I class Parent { public:
double Fl(double x) { return x*x; }
double F2(double x) { return Fl(x)/2; }
class Child : public Parent { public:
double Fl(double x) { return x*x*x; } };
void main() {
Child child;
cout “ child.F2(3) “ end1;
}
Листинг 3.9. Неопределенное позднее связывание.
Класс Parent содержит функции-члены Fl и F2, причем F2 вызывает, El,. Класс Child, производный от класса Parent, наследует функцию F2, однако переопределяет функцию Fl. Вместо ожидаемого результата 13.5 программа выдаст значение 4.5. Дело в том, что компилятор оттранслирует выражение child. F2 (3) в обращение к унаследованной функции Parent: :F2, которая в свою очередь вызовет Parent: :F1, а не Child: :F1, что поддержало бы полиморфное поведение.
C++ однозначно определяет позднее связывание в момент выполнения и обеспечивает полиморфное поведение функций посредством их виртуализации. Листинг 3.10 обобщает синтаксис объявления виртуальных функций в базовом и производном классах.
jclass classNamel {
// Другие функции-члены
virtual returnType functionName(<список параметров>) ;
};
class className2 : public classNamel {
// Другие функции-члены
virtual returnType functionName(<cmicoK параметров>) ;
};
Листинг 3.10. Объявление виртуальных функции в иерархии классов.
Чтобы обеспечить полиморфное поведение функции F1 в объектах классов Parent и Child, необходимо объявить ее виртуальной. Листинг 3.11 содержит модифицированный текст программы.
class Parent {
public:
virtual double F1(double x) { return x*x; }
double F2(double x) { return Fl(x)/2; }
};
class Child : public Parent { public:
virtual double F1(double x) { return x*x*x; }
);
void main() {
Child child;
cout “ child.F2(3) “ endl;
}
Листинг 3.11. Позднее связывание виртуальных функций.
Теперь программа выдаст ожидаемый результат 13.5. Компилятор оттранслирует выражение child. F2 (3) в обращение к унаследованной функции Parent: : F2, которая в свою очередь вызовет переопределенную виртуальную функцию потомка Child: :F1.
Если функция объявлена в базовом классе как виртуальная, ее можно переопределять только в производных классах и обязательно с тем же списком параметров. Если виртуальная функция производного класса изменила список параметров, то ее версия в базовом классе (и во всех его предшественниках) станет недоступной. Поначалу такая ситуация может показаться тупиковой - и на деле оказывается таковой в языках ООП, которые не поддерживают механизм перегрузки. C++ решает проблему, допуская использовать не виртуальные, а перегруженные функции с тем же именем, но с другим списком параметров.
Функция, объявленная виртуальной, считается таковой во всех производных классах - независимо от того, объявлена ли она в производных классах с ключевым словом virtual, или нет.
Используйте виртуальные функции для реализации специфического поведения объектов данного класса. Не объявляйте все ваши методы виртуальными - это приведет к дополнительным вычислительным затратам при их вызовах. Всегда объявляйте деструкторы виртуальными. Это обеспечит полиморфное поведение при уничтожении объектов в иерархии классов.
