| ObjString=OBJECT( ObjPos )
| SubSt : String; { поле-значение подстроки }
| { ! }
| CONSTRUCTOR Init(init_line,init_col: Word;
| init_ss : String);
| { ! }
| PROCEDURE Print; VIRTUAL
| {метод вывода SubSt }
| END; CONSTRUCTOR ObjString.Init;
| {инициализация полей объекта }
| BEGIN
| ObjPos.Init( init_line, init_col );
| {задание позиции }
| SubSt := init_ss { задание значения подстроки }
| END;
| PROCEDURE ObjString.Print;
| BEGIN CRT.GotoXY( Col, Line };
| {процедура из библиотеки CRT }
| Write( SubSt ) {печать подстроки в позиции }
| END;
| {Вывод полиморфного объекта (строки или символа) }
| PROCEDURE PrintObj( VAR Obj : ObjPos );
| BEGIN Obj.Print END;
| { =========== ТЕЛО ОСНОВНОЙ ПРОГРАММ ================ }
| VAR ObjSymVar : ObjSym;
| { экземпляр типа ObjSym }
| ObjStringVar : ObjString; { экземпляр типа ObjString }
| BEGIN { Инициализация и вывод: }
| ClrScr; { очистка экрана }
| ObjSymVar.Init( 10, 10, '*' );
| ObjStringVar.Init( 20, 20, '...ПОДСТРОКА...' );
| PrintObj( ObjStringVar ); { вывод строки }
| PrintObj( ObjSymVar ); { вывод символа }
| END.
Рис. 13.7 (окончание)
- 286 -
Весьма важным является наличие слова VAR перед формальным параметром в процедуре PrintObj. В этом случае мы передаем сам объект. Если бы в процедуре PrintObj формальный параметр был описан как параметр-значение (без слова VAR), то процедура работала бы с копией объекта, приведенной к типу формального параметра. В примере на рис. 13.7 это выразилось бы в том, что несмотря на виртуальность методов, вызывался бы метод ObjPos.Print из типа формального параметра.
При объектно-ориентированном программировании на Турбо Паскале приходится все время решать дилемму: «Каким быть методу, статическим или виртуальным?» При решении этого вопроса пользуйтесь следующим критерием: делайте метод виртуальным, если есть хотя бы малейшая вероятность того, что понадобится переопределение этого метода. Это обеспечит расширяемость программ.
Другим критерием выбора может быть скорость выполнения программы. Если объект имеет хотя бы один виртуальный метод, то для него создается таблица виртуальных методов, и каждая переменная этого типа будет иметь связь с этой таблицей. Каждый вызов виртуального метода проходит через обращение к таблице VMT. С другой стороны, статические методы вызываются «напрямую», поэтому вызов статического метода происходит быстрее, чем виртуального. А если объект вообще не содержит виртуальных методов, то таблица виртуальных методов не будет создана и, как следствие этого, каждая переменная такого типа не будет поддерживать связь с таблицей VMT.
Так что выбор надо делать между некоторым (малозаметным) увеличением скорости вычислений при эффективном использовании памяти, которое дают статические методы, и гибкостью, предоставляемой виртуальными методами.
Объекты могут быть размещены в динамической области памяти («куче»). Для этого они должны объявляться как ссылки, подобно любым другим динамическим структурам данных:
VAR
ИмяСсылкиНаОбъект : ^ТипОбъекта;
- 287 -
Дальнейшее обращение к объектам и полям тоже будет обычным:
ИмяСсылкиНаОбъект — ссылка на объект,
ИмяСсылкиНаОбъект^ — объект в целом,
ИмяСсылкиНаОбъект^.ИмяПоля— поле данных объекта, ИмяСсылкиНаОбъект^.ИмяМетода — вызов метода объекта.
Динамические объекты могут создаваться стандартной процедурой New:
New( ИмяСсылкиНаОбъект );
Как и обычно, процедура New выделяет в динамической памяти область для хранения данных базового типа ссылки. Турбо Паскаль вводит некоторые расширения для динамического распределения и освобождения объектов. Если динамический объект содержит виртуальные методы, то он должен быть инициализирован с помощью вызова конструктора до вызова всех остальных его методов:
ИмяСсылкиНаОбъект^. ИмяКонструктора( параметры );
В Турбо Паскале процедура New расширена. Она позволяет в одной операции выделить память под объект и вызвать конструктор:
New( ИмяСсылкиНаОбъект, ИмяКонструктора( параметры ) );
