Импорт листингов

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

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

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

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

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

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

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

В исходных текстах классов, в предложениях feature, перечислены компоненты, доступные другим классам. Почему бы, в свою очередь, не включать списки компонентов, полученных от других классов? Язык Modula-2 поддерживает, например, объявление import.

Тем не менее, при ОО-подходе это ничего не дает кроме документирования. Для использования компонента f из другого класса C, данный класс должен быть клиентом или потомком этого класса. В первом случае это означает, что f используется как

a.f

но тогда должно присутствовать объявление a:

a: C

недвусмысленно показывающее, что f компонента C. В случае классов потомков информация будет доступна из официальной документации класса, его плоской краткой формы.

Следовательно, нет необходимости в предложении import. ("Плоская краткая форма", лекция 11)

Тем не менее, удобная графическая среда разработки должна обладать возможностью предоставления программисту информации о поставщиках и предках данного класса и их поставщиках и предках, следуя далее по цепочке.

Дата добавления: 2014-01-07