Оптимизация вызовов

На уровнях 2 и 3 неизбежно использование явных вызовов процедуры подобных my_polygon.set_size (5) для изменения значения атрибута. Существует опасение, что использование такого стиля на уровне 4 негативно скажется на производительности. Тем не менее компилятор может создавать для вызова my_point.set_x (3.7) код столь же эффективный, как и для my_point.x := 3.7 , если бы такое присваивание было бы разрешено.

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

В некоторых языках программирования, особенно в Ada и C++, разработчики могут отметить, какие подпрограммы они хотели бы встраивать. По ряду причин предпочтительно, чтобы эта работа выполнялась в режиме автоматической оптимизации.

[x]. Встраивание кода далеко не всегда применимо, и компилятор гораздо корректнее может принять правильное решение.

[x]. При внесении изменений в ПО, в частности с использованием наследования, встроенная подпрограмма может стать не встроенной. Компилятор выявит такие ситуации гораздо лучше, чем человек.

[x]. В случае больших систем компилятор всегда более эффективен. На основе анализа размера подпрограмм и числа вызовов он может точнее определить, какие подпрограммы целесообразно встраивать. Это опять же существенно в случае изменений ПО, поскольку человек не в состоянии отследить эволюцию каждого фрагмента.

[x]. Программисты могут занять время более полезной работой.

Современная концепция разработки ПО подразумевает, что утомительную, автоматизируемую и тонкую работу по оптимизации нужно возлагать на соответствующие утилиты, а не на человека. Это обстоятельство является одной из причин принципиальной критики C++ и Ada. Мы вернемся к этому вопросу при обсуждении двух других ключевых моментов объектной технологии - управления памятью и динамического связывания. (См. "Требования к сборщику мусора", лекция 9, и "Подход C++ к связыванию", лекция 14)

Архитектурная роль селективного экспорта

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

Без селективного экспорта единственным решением будет введение нового типа модулей, представляющего собой группу классов. Такие супермодули - аналоги пакетов Ada и Java - будут осуществлять скрытие информации и экспорт по своим правилам. Добавление в элегантную структуру, основанную на классах, нового и частично несовместимого модульного уровня приведет к усложнению и увеличению объема языка.

Лучшим решением является использование в качестве супермодулей самих классов. Такой подход реализован в Simula, допускающем вложение классов. Однако он не дает ощутимых преимуществ.

Простота объектной технологии в значительной степени базируется на использовании простой концепции модулей. Поддержка классами повторного использования основана на возможности их извлечения из контекста, сохраняя лишь их логические зависимости. Существует риск потери этих преимуществ, если ввести супермодули. В частности, становится невозможным непосредственное повторное использование класса, являющегося частью пакета. Придется либо полностью импортировать весь пакет, либо делать копию класса. Явно непривлекательная форма повторного применения.

Необходимость объединения классов в структурированные коллекции сохраняется. В данной книге она реализована через понятие кластера (лекция 10 курса "Основы объектно-ориентированного проектирования"). Однако понятие кластера относится к области управления и организации. Если включить его в качестве языковой конструкции, то это угроза потери простоты ОО-подхода и его поддержки модульности.

Если необходима группа классов, в которой каждый наделен специальными привилегиями, то нет нужды в супермодулях. Простое решение обеспечивается за счет селективного экспорта, что позволяет сохранить классам свой независимый статус.