Основы объектно-ориентированного программирования

К улучшению эффективности, растущему с увеличением размера и сложности программ, автоматическая подстановка кода добавляет преимущество большей надежности и гибкости. Как уже отмечалось, подстановка кода семантически корректна только для процедуры, которую можно статически ограничить, например, как в случаях (1) и (2). Это не только допустимо, но также вполне согласуется с ОО-методом, в частности, с принципом Открыт-Закрыт, если разработчик на полпути разработки большой системы добавит переопределение некоторого компонента, имевшего к этому моменту только одну реализацию. Если же код процедуры вставляется вручную, то в результате может получиться программа с ошибочной семантикой (поскольку в данном случае требуется динамическое связывание, а вставка кода, конечно, означает статическое связывание). Разработчики должны сосредотачиваться на построении корректных программ, не занимаясь утомительными оптимизациями, которые при выполнении вручную приводят к ошибкам, а на деле могут быть автоматизированы.

Имеются и некоторые другие требования для того, чтобы подстановка кода была корректной, в частности, она применима только к нерекурсивным вызовам. Даже корректную подстановку следует применять при разумном соотношении между временем и памятью: подставляемая процедура должна быть небольшой и должна вызываться небольшое число раз.

Последнее замечание об эффективности. Опубликованная статистика для ОО-языков показывает, что где-то от 30% до 60% вызовов на самом деле используют динамическое связывание. Это зависит от того, насколько интенсивно разработчики используют специфические свойства методов. В системе ISE это соотношение близко к 60%. С использованием только что описанных оптимизаций платить придется только за динамическое связывание только тех вызовов, которые действительно в нем нуждаются. Для оставшихся динамических вызовов накладные расходы не только малы (ограничены константой), но и логически необходимы, - в большинстве случаев для достижения результата, эквивалентного динамическому связыванию, придется использовать условные операторы (if ... then ... или case ... of ...), которые могут оказаться дороже приведенного выше простого механизма, основанного на доступе к массивам. Поэтому неудивительно, что ОО-программы, откомпилированные хорошим компилятором, могут соревноваться с написанным вручную кодом на C.

Кнопка под другим именем: когда статическое связывание ошибочно

К этому моменту должен стать понятным главный вывод из изложенных в этой лекции принципов наследования:

Принцип динамического связывания

Если результат статического связывания не совпадает с результатом динамического связывания, то такое статическое связывание семантически некорректно.

Рассмотрим вызов x.r. Если x объявлена типа A, но в процессе вычисления была присоединена к объекту типа B, а в классе B компонент r переопределен, то использование в этом вызове исходной версии r из класса A - это не вопрос выбора, это просто ошибка!

Безусловно, имелись причины для переопределения r. Одной из них могла быть оптимизация, как в случае с компонентом perimeter в классе RECTANGLE, но могло также оказаться, что исходная версия r просто некорректно работает для объектов из B. Рассмотрим, например, эскизно описанный класс BUTTON (КНОПКА), являющийся наследником класса WINDOW (ОКНО) в некоторой оконной системе (кнопки являются специальным видом окон). В этом классе переопределена процедура display, так как изображение кнопки немного отличается от изображения обычного окна (например, нужно показать ее рамку). В этом случае, если w имеет объявленный тип WINDOW, но динамически связана, благодаря полиморфизму, с объектом типа BUTTON, то вызов w.display должен исполняться для "кнопочной" версии! Использование display из класса WINDOW приведет к искажению изображения на экране.

Мы не должны позволить, чтобы нас обманула гибкость системы типов, основанная на наследовании, особенно ее правило совместимости типов, позволяющее объявлять сущность на уровне абстракции более высоком, чем уровень типа присоединенного объекта во время конкретного выполнения. Во время выполнения программы единственное, что имеет значение, - это те объекты, к которым применяются компоненты, а сущности - имена в тексте программы - уже давно забыты. Кнопка под любым именем остается кнопкой, независимо от того, названа ли она в программе кнопкой или присоединена к сущности типа окно.