Позднее связывание
Cтраница 2
Поэтому метолы интерфейсов Автоматизации рабогают с офапи-ченпым набором типов данных, пригодных для конвертации через вариант. Именно потому, что при маршалппгс длспннтерфейсов не требуются заместитель и заглушка, дпспннтсрфейсы поддерживают позднее связывание. [16]
В промышленности ранним связыванием является заказ деталей заранее. Напротив, производство продукта точно в срок требует от поставщиков способности предоставлять требуемые детали прямо на месте, без предварительного заказа. Такая схема представляет собой пример позднего связывания. [17]
Полиморфизм обеспечивает единую линию поведения различных объектов семейства при вызове одного и того же метода. Это позволяет определить программный интерфейс взаимодействия с объектом и, в дальнейшем, однотипно работать со всеми объектами, реализующими этот интерфейс. Таким образом, появляется возможность позднего связывания - добавления функциональных возможностей в программу не на этапе компиляции, а во время выполнения. [18]
В промышленности ранним связыванием является заказ деталей заранее. Напротив, производство продукта точно в срок требует от поставщиков способности предоставлять требуемые детали прямо на месте, без предварительного заказа. Такая схема представляет собой пример позднего связывания. [19]
Программа должна содержать адрес правильной версии функции в каждом объекте. Точнее, она хранит адрес таблицы адресов виртуальных функций. Кроме дополнительного объема памяти, это требует косвенного вызова функций, что приводит к более медленной работе по сравнению с вызовом стандартных функций. Поэтому рекомендуется делать функцию-член виртуальной только тогда, когда требуется действительно позднее связывание. [20]
В Delphi существует два способа активизации позднего связывания. Можно объявить метод как виртуальный ( как вы уже видели), или объявить его динамическим. Синтаксис использования ключевых слов virtual и dynamic абсолютно одинаковый и результат их использования тоже одинаковый. Различным является лишь внутренний механизм, используемый компилятором для реализации позднего связывания. [21]
Как мы видели, для обращения к объектам в операционных системах используются различные типы имен. Иногда преобразование имени в объект является фиксированным, а иногда нет. В последнем случае может быть важным, когда имя связывается с объектом. Вообще говоря, раннее связывание проще, но не обладает гибкостью, тогда как позднее связывание сложнее, зато часто является более гибким. [22]
Деструктор решает эту проблему так: он идет туда, где хранится нужная информация: - в таблице виртуальных правил переменной экземпляра. В таблице VMT каждого типа объекта имеется размер в байтах типа объекта. Таблица VMT для каждого объекта доступна через невидимый параметр Self, передаваемый правилу по любому вызову правила. Деструктор представляет собой просто особый вид правила, и он получает копию параметра Self в магазин ( стек), когда объект вызывает его, т.е. хотя объект может быть полиморфным во время компиляции, он никогда не может быть полиморфным во время выполнения вследствие позднего связывания. [23]
Для большей части структур данных в операционных системах чаще применяется раннее связывание, но иногда для гибкости используется позднее связывание. К этому вопросу имеет отношение выделение памяти. Если эта программа когда-либо выгружалась на диск, ее нужно было потом загрузить в те же адреса памяти, в противном случае она не могла работать. Напротив, виртуальная память с постраничной подкачкой представляет собой пример позднего связывания. Фактический физический адрес, соответствующий данному виртуальному адресу, неизвестен до тех пор, пока страница не будет физически перенесена в память. [24]
 |
Результат выполнения программы NewDate с использованием наименования дней и месяцев в соответствии с региональными установками. [25] |
Многие разработчики полагают, что первое решение в любом случае будет наилучшим, поэтому объявление большинства полей защищенными сделает класс более расширяемым и облегчит написание классов-наследников. Однако такой подход нарушает идею инкапсуляции. В большой иерархии классов изменение определения защищенных полей основных классов становится столь же трудным, как изменение глобальных структур данных. Если 10 производных классов обращаются к этим данным, то изменение его определения означает потенциальную необходимость изменения программного кода в каждом из этих 10 классов. Другими словами, удобство, возможность расширения и инкапсуляция часто противоречат друг другу. В таких случаях предпочтение необходимо отдать инкапсуляции. Часто это промежуточное решение может быть получено с помощью виртуального метода. Этот аспект будет рассмотрен в разделе Позднее связывание и полиморфизм. Если вы в ущерб инкапсуляции предпочтете обеспечить быстрое написание про-граммного кода классов-наследников, то может получиться, что ваша разработка не будет отвечать принципам ООП. [26]
Страницы: 1 2