В Камаев - Технологии программирования

Обязанности объектов класса Класс_1:

— обеспечивать возможность работы с дочерними компонентами;

— обеспечивать возможность копирования данных в другой объект того же класса;

— обеспечивать возможность уничтожения объекта с высвобождением памяти;

— обеспечивать возможность посылать сообщения;

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

Обязанности объектов класса Класс_2:

— обрабатывать сообщения от клавиатуры;

— получать фокус ввода;

— определять, имеется ли фокус ввода;

— определять, может ли объект иметь фокус ввода (например, если элемент невидим, ему нельзя передать фокус ввода);

— обрабатывать сообщение BM_CLICK (происходит после нажатия кнопки мыши);

— становиться видимым и невидимым;

— перерисовываться;

— обеспечивать возможность перевода точки из системы координат окна в систему координат экрана;

— хранить идентификатор родителя (с возможностью изменить родителя).

Обязанность объектов класса Класс_3:

— обрабатывать сообщения WM_LBUTTONDOWN и WM_LBUTTONDBLCLK (нажатие и двойное нажатие левой кнопки мыши).

Обязанности объектов класса Класс_4:

— очищать список;

— обеспечивать возможность нахождения нескольких элементов из списка;

— определять номер элемента списка по координатам точки, принадлежащей объекту класса TDBListBox.

Теперь, исключив из множества обязанностей объектов рассматриваемых классов те, которые переданы дополнительным классам, перечислим оставшиеся обязанности:

Обязанности класса TDataSource:

— контролировать доступ пользователя к элементам TDataSet;

— обеспечивать возможность определения, подключен ли TDataSource к некоторому элементу TDataSet.

Итак, обязанности класса Tbutton — программно эмулировать нажатие кнопки; класса TradioButton — определять, какая из кнопок с зависимой фиксацией выбрана; классов TlistBox и TDBListВох — обеспечивать связь с источником данных (TDataSource).

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

Теперь рассмотрим на рис. 8.13 фрагмент схемы иерархии классов для перечисленных элементов (до корневого суперкласса).

Сравнивая рисунки 8.12 и 8.13, можно заметить:

1. Класс_1 в нашей иерархии соответствует ветви TObject → TPersistent → TComponent;

2. Класс_2 — TControl —> TWinControl;

3. Класс_3 — TbuttonControl;

4. Класс_4 — TCustomListBox.

Если с двумя последними классами все понятно, то возникает вопрос: почему первые два класса нашей иерархии соответствуют не одному, а целым цепочкам классов C++ Builder? Дело в том, что в рассматриваемом примере описаны не все классы C++ Builder. Поэтому те из них, которые приводят к разветвлению двух первых цепочек, здесь просто не учтены. Например, элемент TImage, предназначенный для расположения на формах графических изображений, имеет следующую цепочку наследования классов: TObject → TPersistent → TComponent → TControl → TGraphicsControl, — т. е. цепочка TControl → TWinControl превращается в дерево, на котором классы TWinControl и TGraphicsControl оказываются на одном уровне. Данный фрагмент схемы иерархии классов изображен на рис. 8.14.

Рис. 8.12. Предварительная иерархия классов

Рис. 8.13. Иерархия некоторых классов C++ Builder

Рис. 8.14. Фрагмент схемы иерархии

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

Вначале надо ввести всего одно понятие, предложенное Александром Усовым: контейнер-менеджер, или просто контейнер. Следует отметить, что здесь не идет речь о контейнере C++. Итак, контейнер — это класс, который позволяет объединять (агрегировать) в себе самые разные классы объектов, в том числе и другие контейнеры. Одной из наиболее сложных задач проектирования является агрегация разнородных элементов в новое единое целое. Контейнер — один из механизмов решения проблемы гибкой агрегации.

Простейший контейнер — это список ссылок на объекты. Далее если воспользоваться механизмом сообщений, то… всех этих затруднений можно избежать! Ни строчки нового кода! Сообщения, приходящие контейнеру, проецируются на принадлежащие ему объекты. Но допустима и более сложная логика обработки запросов, перед тем как они попадут к объекту-обработчику.

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

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

Контейнеры бывают двух типов: однородные (динамические) и разнородные (статические).

Однородный контейнер может включать произвольное множество объектов одного класса либо классов, производных от данного класса. Логика работы такого контейнера предельно проста, например распределять поступающие сообщения по всем включенным в него объектам. Поскольку включенные в него объекты принадлежат одному классу, то, следовательно, они имеют единый интерфейс, но тогда становится совершенно неважно, сколько объектов включено в контейнер в любой момент времени, т. е. это число произвольно. Логика работы такого контейнера с включенными в него объектами одинакова и не зависит от конкретного объекта. Типичный представитель такого контейнера — список (например, строк). При добавлении (удалении) новых объектов (строк) логика работы самого контейнера остается неизменной.