Полиморфические наборы
-----------------------------------------------------------------
Как вы уже видели, что наборы могут динамически хранить лю- бой тип данных, и они обладают множеством методов, которые помо- гают вам организовывать эффективный доступ к данным. В действи- тельности сам TCollection определяет 23 метода. Когда вы исполь- зуете наборы в ваших программах, вы будете удивлены скоростью их работы: они разработаны с максимальной гибкостью и реализованы для использования с максимальной скоростью.
Теперь пришло время рассмотреть реальные возможности набо- ров, элементы могут обрабатываться полиморфически. Это значит, что вы не просто можете хранить определенный тип объекта в набо- ре; вы можете хранить несколько разных типов объектов, взятых произвольно из вашей иерархии объектов.
Если вы рассмотрите приведенные примеры наборов, вы можете заметить, что все элементы каждого набора были одно и того же ти- па. Мы имели дело со списком строк в котором каждый элемент был строкой. Мы также занимались списком клиентов. Но наборы могут хранить любые производные от TObject объекты, и вы можете произ- вольно смешивать эти объекты. Естественно, что вы желаете, чтобы эти объекты имели нечто общее. На самом деле вам нужно, чтобы у них был общий абстрактный объект-предок.
В качестве примера рассмотрим программу, которая помещает в набор три различных графических объекта. Затем итератор ForEach используется для просмотра набора и отображения каждого объекта. В отличие от других примеров данной главы данный пример (Collect4) использует функции Windows для рисования в окне. Обя- зательно включите WinProcs и WinTypes в uses данного примера. Сначала определяется абстрактный объект-предок (см. COLLECT4.PAS).
type PGraphObject = ^TGraphObject; TGraphObject = object(TObject) Rect: TRect; constructor Init(Bounds: TRect); procedure Draw(DC: HDC); virtual; end;
Из этого объявления вы можете видеть, что каждый графический объект может инициализировать себя (Init) и отобразить себя на графическом экране (Draw). Теперь определим эллипс, прямоугольник и сектор как производные от этого общего предка:
PGraphEllipse = ^TGraphEllipse; TGraphEllipse = object(TGraphObject) procedure Draw(DC: HDC); virtual; end;
PGraphRect=^TGraphRect; TGraphRect=object(TGraphObject) procedure Draw(DC: HDC); virtual; end; PGraphPie = ^TGraphPie; TGraphPie = object(TGraphObject) ArcStart, ArcEnd: TPoint; constructor Init(Bounds: TRect); procedure Draw(DC: HDC); virtual; end;
Все эти три типа объекта наследуют поле Rect из TGraphObject, но все они разного размера. TGraphEllipse и TGraphRect нужно только добавить их новые методы рисования, т.к. их методам рисования нужны только размеры и расположение, а TGraphPie нужны дополнительные поля и другой конструктор для их корректного представления. Приведем исходный код для помещения этих фигур в набор:
. . . GraphicsList := New(PCollection, Init(10,5)); { создать набор } for I := 1 to NumToDraw do begin case I mod 3 of { создать объект } 0: P := New(GraphRect, Init(Bounds)); 1: P := New(GraphEllipse, Init(Bounds)); 2: P := New(GraphPie, Init(Bounds)); end; GraphicsList^.Insert(P); { добавить в набор } end; . .
Как вы можете видеть цикл, for вставляет графические объекты в набор GraphicsList. Вы знаете только то, что каждый объект в GraphicsList представляет собой некоторый вид TGraphObject. После помещения в набор у вас уже нет информации о том, является ли элемент набора прямоугольником, эллипсом или сектором. Благодаря полиморфизму, вам этого и не нужно знать, поскольку каждый объект содержит все данные и код (Draw), который ему нужен. Просмотрим набор с использованием итеративного метода и каждый набор будет сам отображать себя:
procedure DrawAll(C: PCollection);
procedure CallDraw(P: PGraphObject); far; begin P^.Draw(PaintDC); { вызов метода Draw } end;
begin {DrawAll} C^.ForEach(@CallDraw); { прорисовать каждый объект } end;
var GraphicsList: PCollection; begin . . . if GraphicsList <> nil then DrawAll(GraphicsList); . . . end.
Способность наборов хранить разные, но связанные объекты ос- новывается на мощном краеугольном камне объектно-ориентированного программирования. В следующей главе вы увидите тот же принцип по- лиморфизма, примененный к потокам с равными приоритетами.
