destructor Destroy; virtual;
Собственно деструктор. Вызывается методом Free после удостоверения в том, что экземпляр пока существует. Есть одно замечание по поводу именования деструктора - он должен называться Destroy, это связано с его виртуальностью, а соответственно и перегрузкой. Если Вы назовете деструктор другим именем, то при попытке вызвать унаследованный метод RTM не найдет описание метода с вашим именем, а это повлечет за собой нарушение функциональности процедуры разрушения объекта. Однако интересно отметить одну деталь. Наличие вызова унаследованного деструктора не обязательно, хотя и желательно - ведь не все разработчики любят обрабатывать события времени исполнения, а освобождение памяти, отведенной под экземпляр, произойдет без участия кода, описанного в деструкторе.
Давая описание методам базового класса TObject, я пытался дать представление об объектной модели Delphi, о жизненном цикле объекта, о методах использования объектов в собственных программах и правилах перегрузки. Как видно из вышесказанного основой для работы с экземплярами является VMT, и использование RTTI не всегда необходимо для выполнения некоторых специфических операций с экземпляром. Использование же RTTI, на мой взгляд, не всегда оправдывается, однако при написании RunTime редакторов компонент это средство достаточно удобно.
В результате изучения исходного кода обнаружился интереснейший момент - при вызове любого метода в EAX находится указатель … на VMT! Не это ли является явным указанием на объектную ориентированность Delphi?! Изучая материалы книги "Delphi in nutshell" Рэя Лишнера (Ray Lischner) я наткнулся на интересный факт - таблицу сравнения объектных моделей некоторых языков, позволю себе привести ее с некоторым переводом и дополнениями:
Поддерживаемые возможности объектных моделей некоторых языков программирования.
Тут видны некоторые особенности, которые не очевидны на первый взгляд. Что же такое динамические методы? Сразу стоит оговориться - это модификатор способа вызова метода, и по этому его сразу надо поставить в один ряд с другими способами вызова методов - статическими, виртуальными и репредставительными. Чем же они отличаются и когда они нужны?
Статические методы (их аналог в Java - final, финальные) являются не перегружаемыми методами, их функциональность окончательна, например конструктор Create класса TObject - он пуст и никакой дополнительной деятельности не несет, по этому вызов этого метода не полиморфен. По этому, если вы хотите перегрузить статический метод, то Вам придется заново описывать всю его функциональность.
Виртуальные методы это методы, которые позволяют формировать цепочки полиморфных вызовов посредством статического связывания через таблицу виртуальных методов VMT. Это выгладит приблизительно так:
Чтобы быть полностью точным, надо сказать, что в таблице указаны все виртуальные методы, определенные в родителях плюс внутри самого класса. Если есть перегруженные методы, то в таблице на соответствующих местах ставятся входные точки новых методов, если же нет - то входные точки методов родителей. Таким образом, можно точно сказать, какой метод надо вызывать при обращении к таблице виртуальных методов.
Динамические методы хранят точки входа в специальной таблице динамических методов, эта таблица строится только для измененных или добавленных методов. Таким образом храниться меньше информации о классе, но вызов методов происходит дольше, вследствие линейного поиска метода в таблице динамических методов класса и его родителей, на что затрачивается некоторое время.
Репредствавительные методы это методы, функциональность которых переопределена полностью относительно родителя. Вообще-то указание директивы reintroduce не обязательно, но это избавит Вас от лишнего предупреждения о перегрузке метода со стороны компилятора.
Еще одна интересная особенность TObject - это хранение на уровне VMT информации о трех методах с интересным названием: QueryInterface, AddRef и Release. То есть любой класс, созданный в рамках объектной модели Delphi является COM объектом! Единственным ограничением здесь является то, что для функционирования этих методов необходимо унаследовать хотя бы один интерфейс, что и сделано в рамках другого базового класса TInterfacedObject.
Внимание! Запрещается перепечатка данной статьи или ее части без согласования с автором. Если вы хотите разместить эту статью на своем сайте или издать в печатном виде, свяжитесь с автором.