лекция 12 (Языки программирования (лекции) (2008))

Языки программирования.

Лекция 12.

Модульные языки (продолжение).

Напомним о том, что мы рассматриваем именно модульные яп, и определения новых тд опирается, прежде всего, на понятие модуля (см. лекция 11 о Модуле 2 и Дельфи). У нас есть глобальное пространство имен, в котором в начале непосредственно видимы только имена библиотечных модулей и главного модуля. Имена, которые определены в модуле определений (или интерфейсной части юнита для Дельфи), видимы потенциально. Локальными именами (видимыми только в пределах данного модуля) являются те, которые определены в модуле определений (implementation модуле). Пространство имен достаточно структурируемо. Есть специальная конструкция:

Uses список_имён_модулей; - для Дельфи

IMPORT список_имен_модулей; - для Модула 2

Разница конструкций в том, что uses сразу делает непосредственно видимыми все имена из соответствующих модулей, а Модуле 2 они видимы потенциально.

FROM или IMPORT список_имён; - вторая форма для Модулы 2, при таком обращении имена становятся непосредственно видимыми.

Требуется только, чтоб имена модулей внутри одного проекта не конфликтовали, этого добиться не очень сложно. А если имена конфликтуют: если свое имя конфликтует с импортированным, то свое видимо непосредственно, а импортированное потенциально, если оба чужих имени – то оба потенциально (по средствам явного уточнения).

Отметим, что явное уточнение может быть неудобно при написании программ, зато повышает их читабельность. Такая модель принята во многих яп, например, в Python, Оберон.

3)

Замечание 1.

В предварительной версии языка Оберон (1988 год) речь шла о двух видах модулей.

1.DEFINITION M;

...

ENDM.//модуль определений

2.MODULE M;

END M. // модуль реализации

Но в отличие от Модула 2 – отсутствует понятие главного модуля. Оберон - язык для некоторой операционной системы для некоторой рабочей станции (и система, и язык назывались Оберон). Есть понятие команда – это процедура без параметров, которая описана в каком-то модуле определений. С системой мы работаем в интерактивном режиме и если у нас есть модуль М и в нем есть процедура Р, то M.P – вызывая тем самым определенную команду, иными словами любая команда, написанная в любом модуле динамически подгружается, и автоматически становится доступной как интерактивная команда соответствующего shell’а. поэтому понятие главной программы просто отсутствует, поскольку в определенном смысле главной программой может стать любая процедура без параметров в соответствующем модуле определений.

В таком результате возникает некоторая избыточность, так как описанные типы данных и объекты дублировать в модуле реализаций не нужно, а заголовки процедур – нужно. Понятие модуля определений является избыточным, так как можно сделать по-другому - если объединить понятия модуля определения и модуля реализации. Так в окончательной версии языка (1990 год) – вся программа состоит только из модулей одного вида. Есть специальная конструкция - экспорт, то если у нас есть некоторый тип данных Т, который должен быть экспортирован, мы помечаем его звёздочкой (аналогично - в определениях процедур). Причем помечаем звездочкой в определении, каждое имя должно быть определено и только один раз.

O ~ MODULE M;

...

END M.

TYPE T* =

PROCEDURE P*(X:T)

Принцип «звездочки» (*) относится и к именам – рассмотрим пример с полями записи:

TYPE T*=RECORD //видно имя Т

X:INTEGER; // пользователь не имеет доступ, для языков с классами – аналогия с private и protected

Y*:REAL; //пользователь имеет доступ к имени У внутри типа Т, для языков с классами – аналогия с public

END;

Y*-:REAL; // Переменная доступна только для чтения, модифицировать ее могут только процедуры изнутри этого модуля.

Вирт объяснял такой подход тем, что понятие экспорта сводится к понятию проекция, т.е. на примере записи – все ее видимы части – это ее проекция. Таким образом, проекция не может быть шире исходного объекта, но может быть уже. Крайний случай – если открыто имя типа и закрыты все члены данных. В результате у нас всего одно понятие (модуль), а интерфейсная часть скрыта внутри модуля.

Тут есть некоторая тенденция. В старых ЯП, которые разрабатывались в 70-80 года прошлого века, был реализован принцип языкового дизайна - Разделение Определения, Реализации и Использования (РОРИ). На примере Модула 2 мы видим – разделение определения, реализации и использования – в разделении программы на различные модули. Главной задачей модуля (кроме главного) является экспорт различных услуг - иногда принцип назывался РОРИУС (и УСлуги).

В языках этого времени раздельно было определение и реализация (уже рассмотрено в Модула 2, Дельфи, и еще увидим в Ада). В Пакетах языка Ада есть отдельно определение пакета и отдельно реализация. В языке Оберон (90-й год) понятие интерфейса, в явном виде как языковая конструкция, не существует - отказались от понятия модуля определения.

В языке Си++ поддерживается разделение реализаций.

• class X {

int f(); // обязаны указать прототип, а тело ниже

} // описание класса

• реализация класса – есть тела функций описанных в нем

inline int X::f() { ... } // реализация функции

В языках 90-х годов определение и реализация слиты воедино. В Си# и языке Java - если метод не абстрактный, то его реализация обязана присутствовать непосредственно в классе (что делает соответствующий класс трудночитаемым). Почему так произошло – в 90-х годах уже практически не разделяли язык и среду программирования. Первоначально языки проектировались без учёта того, что среда программирования возникает возле него.

Уже с конца 80-х годов начало учитываться то, что интегрированная среда программирования будет "обёртывать" ЯП.

То же самое относится и к понятию интерфейсов, т.е. во всех языках, про которые мы говорим, предполагается, что в системе программирования будет некоторое средство – документатор, которое умеет из модуля исходного текста «вылеплять» интерфейсы и представлять их в удобном и читаемом виде. Например, в ОС Оберон существует утилита, на вход которой идёт текст модуля и она генерирует интерфейсный модуль (псевдомодуль определений).

Пусть у нас есть тип Т, его поля Х и процедура Р, которые экспортируется, то псевдомодуль(не существует как конструкция для компилятора, но существует как единица документации) будет таким:

DEFINITION M;

TYPE T=RECORD

X:INTEGER;

END;

PROCEDURE P(X:T);

END M;

И Си# и языке Java есть специальные утилиты. JavaDoc, которая умеет по тексты Java-класса экстрагировать только те имена, которые являются публичными, т.е. относятся к определению, и представлять результат этого экстрагирования в виде усеченной Java- программы (либо в виде текста, либо в виде HTML). Таким образом получается документация программы.

class X {

public void f(X y) //кликнув на соответствующую ссылку – получаем информацию о функции, классе

}

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

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

Замечание 2.

В Обероне структура пространства имён остается точно такой же. Общее пространство имен – имена модулей, которые видимы непосредственно. В Обероне это единственные объекты, которые видимы непосредственно. Все остальные имена, которые экспортируются при помощи конструкции "*", они видны только потенциально (M1.имя). снять эту потенциальную видимость нельзя.

Существует единственная конструкция импорта:

IMPORT список_имён_модулей

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

На это закончим с простейшей моделью видимости, которая обобщает модель видимости языка ассемблер, и рассмотрим модель видимости языка Ада.

4) В языке Ада есть понятие пакета. Пакет делится на 2 части: спецификация и тело пакета. Идейно это похоже на модуль определений и модуль реализаций языка Модула-2.

• Спецификация пакета - только объявления и заголовки

package P is

объявление // здесь могут быть вложенные пакеты, основное отличие от ранее рассмотренных языков

[приватная часть] // необязательна

end P.

• Тело пакета: для каждой спецификации может существовать тело пакета (а может и не существовать - как в Модуле-2):

package body P is

реализация процедур и функций из спецификации

end P;

Если есть вложенные пакеты, то тела вложенных спецификаций находятся внутри тела пакета.

Чем отличаются вложенные пакеты от глобальных? Рассмотрим два стандартных подхода проектирования программных систем:

1. Нисходящий (top-down) - вначале проектируем модуль верхнего уровня, специфицируем, что нужно от других уровней и их проектируем. Соответствует технологии структурного программирования, каждый модуль представляется как некий черный ящик, который начинают детализировать только на очередном уровне разработке.

2. Восходящий (bottom-up) - сначала проектируем модули самого нижнего уровня (например, те которые занимаются вводом-выводом), а потом на их основе проектируем модули более высокого уровня, и т.д. пока не спроектируем самый главный модуль. Сначала проектируем сервисные модули, потом поднимаемся дальше, пока не спроектируем модуль высшего уровня. При дизайне ОС – такой подход весьма продуктивный, обеспечивает расслоение – выделяет уровни абстракций, позволяет свести интерфейс между этими уровнями абстракций до разумного минимума. Очевидный недостаток - главный модуль появляется самым последним (что не очень хорошо для отчёта перед заказчиком).

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

Когда программа вытягивается в линейную последовательность сервисных модулей. Это соответствует восходящей последовательности. У нас есть глобальное пространство имен, и модули добавляют в это пространство свои экспортируемые имена. В такой системе клиентский модуль (использует импорт) знает о существовании сервисных модулей, а сами сервисные модули ничего не знают о клиентских. Это одностороннее связывание модулей.

В большинстве яп существующая технология проектирования модулей она поддерживает в явном виде только восходящий стиль программирования.

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

package P is

package P1 is

package P11 is

end Р11;

end P1;

end P;

Спрашивается: к каким ресурсам могут обращаться эти пакеты? Что видят Р1 и Р11? Они могут ссылаться не только на ресурсы друг друга, но и на ресурсы модуля, который их содержит. Более того, сами тела пакетов могут ссылаться на объекты, которые описаны в теле пакета. Этого нельзя достигнуть при использовании схемы с односторонним связыванием, там имена, описанные в модуле реализации, недоступны никому, тут они доступны реализациям внутренних пакетов. Здесь связь двусторонняя – Р является клиентским по отношению к Р1 и Р11, и в то же время Р1 и Р11 являются клиентскими по отношению к Р (могут использовать как внешние так и внутренние ресурсы). Такая технология проектирования поддерживает нисходящий метод.

Большинство современных ЯП не поддерживают вложенную структуру. Классы могут быть вложенными, но, учитывая практику использования таких концепций, вложенные классы используются значительно реже, чем внешние. Человек не любит вложенных структур, он любит последовательные структуры. Объектов 20 уже тяжело удерживать в мозгу, и их надо структурировать.

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

Экспорт и импорт имён:

В языке Ада есть одно глобальное пространство имен, при этом считается, что оно как бы вложено внутрь модуля STANDARD. Любой программный пакет является погруженным в некий модуль STANDARD. Программа состоит из некоторой последовательности библиотечных пакетов, могут быть вложенные пакеты. Имя становится видно с момента его определения.