Попробуем доработать класс TCircle, так чтобы его объекты могли сообщать о своей длине окружности и площади. Еще в школьном курсе геометрии вы привыкли называть длину окружности длиной, а не периметром, но длина уже есть у отрезка. Неужели, чтобы избежать конфликта имен, придется называть это свойство как–то иначе? Нет. При работе с объектом всегда указывается имя объекта, а затем, через точку, имя метода или свойства. Поскольку тип объекта известен, компилятор всегда понимает какую именно подпрограмму вызвать. Таким образом объявление
вполне законно. Разумеется, новые методы необходимо определить в разделе implementation.
Возможность давать одинаковые имена схожим свойствам и действиям весьма важна при разработке больших программ. Без неё пришлось бы придумывать синонимы, префиксы или вводить в имена мелкие отличия, что существенно затруднило бы их использование. Это одно из явлений, получивших общее название полиморфизм. Использование одного имени для обозначения разных действий называется “простым” полморфизмом.
Чтобы познакомиться с другими случаям полиморфизма, обогатим иерархию наших классов. С этой целью добавим еще один тип — эллипс:
Как известно, эллипс может быть получен проекцией окружности на наклонную плоскость. Здесь ф задает угол между плоскостями, а Х — направление линии пересечения этих плоскостей. Таким образом, если окружность дается множеством точек с координатами
то эллипс
и в нашем определении эллипс — это наклоненная окружность.
Обратите внимание на то, что методыLength и Square уже были у класса–предка TCircle. Чтобы переопределить их для TEllipse, методы необходимо повторно указать в объявлении класса и, разумеется, переопределить в разделе реализации, добавив к именам имя класса (TEllipse.Length и TEllipse.Square).
Рассмотрим демонстрационную программу.
Обратите внимание, что переменной c, которая имеет тип TCircle, присваивается то ссылка на окружность, то ссылка на эллипс. Это разрешено, поскольку в результате наследования возникло определение: “Эллипс — это окружность …”.
Почему же возникла ошибка? Дело в том, что объявленные нами методы являются статическими, т.е. адреса конкретных функций были вычислены ещё на шаге компиляции по типу переменной c. Обращение к статическим методам мало чем отличается от обращения к обычным процедурам и функциям.
Подобная ситуация не выдумана, а довольно часто возникает на практике. Причиной тому наследование. Объекты более общего класса могут являться и объектами подкласса. Таким образом, выяснить точный класс объекта еще во время компиляции невозможно, тогда как для вызова статических методов это необходимо, поскольку методы подклассов могут отличаться. ООП предоставляет механизм для решения таких проблем — виртуальные методы.
Чтобы объявить метод виртуальным, необходимо в наиболее общем классе, где этот метод был введен, поставить после него ключевое слово virtual, а во всех классах–наследниках, в которых этот метод отличается от унаследованного, его объявление нужно повторить безо всяких изменений, но ставить после него ключевое слово override.
При реализации методов дескрипторы virtual и override опускаются. Теперь пробная программа будет работать правильно. Для каждого объекта будет вызван его собственный метод.
Вот как это происходит. Помните замечание, что один из ключевых моментов в ООП — создание объектов. Так вот, в процессе создания объекта в него включается указатель на таблицу виртуальных методов (VMT) его класса . Каждый класс имеет собственную таблицу таких методов. Встретив c.Square, компилятор знал, что имеет дело с виртуальным методом. Вместо обращения к функции TCircle.Square он вставил процедуру поиска нужной функции в таблице виртуальных методов. Таким образом, программа сначала обратится к указателю на VMT, это будет таблица в точности того класса к которому принадлежит объект. В таблице содержится указатель на метод Square нужного класса, и именно он будет вызван.
Этот великолепный механизм, который опытные программисты создавали ранее каждый на свой лад, стал одним из серьёзных козырей ООП. В литературе такая схема вызова часто называется поздним связыванием, т.е. выбор адреса конкретной процедуры выполняется уже в процессе работы программы. Полиморфизм связанный с поздним связыванием часто называется “чистым” полиморфизмом.
В качестве еще одной иллюстрации рассмотрим деструктор Destroy. Допустим, вы создали список разнородных объектов. В списке содержатся лишь указатели типа TObject, но указывают они на различных потомков этого класса.
Что делать, когда придет время удалять список? Нужно применить Destroy к каждому ненулевому указателю, а затем освободить и память выделенную под список. Загвоздка в том, что Destroy для каждого класса свой. Какой же из методов будет работать? Опять всегда правильный! Именно для этого сам метод объявлен как virtual, а при его переопределении мы всегда ставим override.
Несколько примеров виртуальных методов приводится в главе посвященной ООПроектрованию.
Предостережение. Если при переопределении виртуального метода вы забудете указать дескриптор override, то ни какой диагностики не последует. Просто ваш метод перестанет быть виртуальным, произойдет обыкновенное перекрытие. Будьте внимательны, ибо обнаружить такую ошибку не просто.
При изучении Delphi вы столкнетесь еще с одним дескриптором — abstract. Abstract означает, что метод только указывает, какими должны быть методы потомков, т.е. определяет интерфейс. Он не имеет реализации и обращаться к нему до появления классов с конкретизацией метода нельзя .
Опубликовал Kest
June 14 2011 10:41:41 ·
0 Комментариев ·
10094 Прочтений ·
• Не нашли ответ на свой вопрос? Тогда задайте вопрос в комментариях или на форуме! •
Комментарии
Нет комментариев.
Добавить комментарий
Рейтинги
Рейтинг доступен только для пользователей.
Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.
Нет данных для оценки.
Гость
Вы не зарегистрированны? Нажмите здесь для регистрации.
Главная
Каталог файлов
