Н. Вирт - Программирование на языке Модула-2 (1160777), страница 16
Текст из файла (страница 16)
Эта жепроцедура может использоваться для вывода ключей в восьмеричном виде, например вызовомОбходДерева(корень,WriteOct)Из этих примеров должно быть ясно, что, хотя процедурные типы редко используются, онипредставляют собой мощное средство программирования.В заключение укажем, что процедуры, присваиваемые переменным или передаваемые какпараметры, не могут быть описаны как локальные в некоторой процедуре. Они также не могутбыть стандартными процедурами (такими, как ODD, INCL и т.д.).Часть 423. МОДУЛИМодули - самая важная черта, отличающая язык Модула-2 от ее предшественника Паскаля.Мы уже встречались с модулями, поскольку каждая программа - это модуль. Однако большинствопрограмм разбивается на нисколько модулей, причем каждый модуль содержит константы,переменные, процедуры и, возможно, типы. Из модуля М можно обращаться к объектам,описанным в других модулях, если эти объекты сделаны доступными, т.е, импортированы вмодуль М.
В примерах предыдущих разделов мы обычно импортировали процедуры ввода ивывода из модулей, содержащих наборы часто используемых процедур. Эти процедуры - вдействительности часть нашей программы, даже если мы их и не программировали, и онитекстуально отделены.Ключевая идея состоит в том, что модули могут храниться в "библиотеке" программ и кним должно производиться автоматическое обращение при загрузке и выполнении программы,непосредственно написанной программистом. Таким образом, оказывается возможным.
заранеезаготовить набор часто используемых операций (таких, как ввод и вывод) и избежатьнеобходимости повторного программирования этих Функций всякий раз, когда они потребуются.Более сложные реализации языка идут в этом отношении, дальше и предлагают средство,называемое раздельной компиляцией. Это означает, что модули запоминаются в библиотеке программне в . виде исходных текстов, а в откомпилированной Форме.
При загрузке программы,компилируемая(главная)программаобъединяется(связывается)стемиранееоткомпилированными модулями, из которых она импортирует объекты. В этом случае компиляторво время трансляции импортирующей программы должен также иметь доступ к описаниям79объектов тех ранее откомпилированных модулей, из которых происходит импорт. Эта чертаотличает раздельную компиляцию от независимой компиляции, присутствующей в типичныхреализациях Фортрана, Паскаля и ассемблера.Любой вспомогательный модуль может в свою очередь импортировать объекты из другихмодулей. Следовательно, программа может представлять собой целую иерархию модулей.Говорят, что главная программа имеет наивысший уровень, а те модули, которые совсем неимпортируют объектов - наинизший.
Обычно программист даже не имеет представления об этойиерархии, поскольку его программа импортирует объекты из модулей, которые он сам не писал и,следовательно, не знает их импорта, а значит, и иерархии модулей, лежащих ниже. Но тем неменее в принципе программа не что иное, как текст, написанный самим программистом ирасширенный текстами импортируемых модулей. Эти расширения обычно очень велики (дажеесли прямой импорт состоит лишь из нескольких процедур вывода). В принципе непрямой импортвключает в себя полностью все окружение, или операционную систему.
В вычислительныхсистемах, ориентированных на одного пользователя. Фактически не требуется ничего, что прямоили косвенно не импортировалось бы главной программой. Однако некоторые модули, такие, какбазовая система ввода-вывода и файловая система, могут запрашиваться всеми программами иФактически становятся резидентными, а следовательно, их можно считать операционнойсистемой.Принципиальное соображение, лежащее в основе разбиения программы на модули (несчитая преимуществ использования модулей, написанных другими программистами), необходимость установления иерархии абстракций. Например, во встречавшихся ранее примерахимпорта процедур ввода-вывода мы просто хотели их иметь и нам не нужно было знать (мы дажене хотели узнавать), как конкретно работают эти процедуры.
Абстрагирование означает"пренебрежение" содержимым и тем самым игнорирование конкретных деталей. Каждый модульпредставляет собой абстракцию, если рассматривать его "снаружи". Мы хотим даже большего: непросто игнорировать детали внутренности модуля, а скрыть их. Первая причина такого желаниязаключается в том, что если внутренность модуля защищена от внешнего доступа, то можногарантировать его правильное функционирование, ограничивая тем самым область поиска ошибкив случае неверного функционирования программы.
Вторая, но не менее важная причина - сделатьвозможным изменение (улучшение) внутренней структуры импортируемого модуля без изменения(и/или перекомпиляции) импортирующего модуля. Такая эффективная декомпозиция модулейпросто необходима при разработке больших программ, в особенности если модулиразрабатываются разными людьми и если мы рассматриваем операционную систему как секциюнизкого уровня в иерархии программных модулей.
Без декомпозиции любое изменение илиисправление в операционной системе или библиотеке модулей было бы Фактическиневозможным.Прямым следствием требования декомпозиции является необходимость текстуальногоразделения внешней спецификации модуля и его внутренних деталей. Внешняя спецификациямодуля -это информация об объектах, которые могут импортироваться другими модулями.Внутренние детали - те части модуля, которые должны быть скрыты и защищены. В Модуле-2декомпозиция достигается разбиением модуля на раздел определений и раздел реализации. Разделопределений содержит описания экспортируемых объектов, и он должен рассматриваться какприставка к разделу реализации. При импорте модуля достаточно иметь доступ только к егоразделу определений: раздел реализации остается в полном распоряжении разработчика модуля.До тех пор пока он меняет лишь раздел реализации (разумным образом), ему не нужно ничегосообщать о своих действиях тем, кто использует модуль.
Оба раздела компилируются отдельно ипоэтому называются единицами компиляции.Завершая это введение в понятие модуля, потребуем, чтобы всякая разумная реализацияобеспечивала полный контроль совместимости типов между объектами независимо от того,описаны они в одном и том же или в разных модулях, т.е. границы модуля не должныограничивать механизм контроля типов в компиляторе.
Однако программисту следует понимать,что и такая проверка не дает абсолютной защиты от ошибок. В конце концов она касается толькоФормальных, синтаксических аспектов и не затрагивает семантическую правильность. Она необнаружила бы, например, ошибочную замену алгоритма вычисления синуса алгоритмом для80косинуса. Но ведь нельзя считать обязанностью компилятора защиту программистов от козней ихколлег.24. РАЗДЕЛ ОПРЕДЕЛЕНИЙ И РАЗДЕЛ РЕАЛИЗАЦИИРаздел определений модуля называется модулем определений. Он содержит описанияэкспортируемых идентификаторов.
Они могут обозначать объекты любого вида, но следуетупомянуть несколько дополнительных правил.Модуль - часть полного текста программы. Следовательно, переменные, описанные вмодуле определений, являются глобальными в том смысле, что они существуют в течение всегопериода выполнения программы, хотя видимы и доступны только в тех модулях, которые ихимпортируют. В остальных модулях они невидимы.Описания процедур в модуле определений состоят из одних заголовков. Тела процедурнаходятся в соответствующем модуле реализации.Если тип описан в модуле определений, то все детали описания видимы в импортирующихмодулях. Если описан тип перечисление или тип запись, то экспорт его имени автоматическиведет соответственно к экспорту имен констант перечисления или имен компонент.
В противовестакому прозрачному экспорту существует еще скрытый экспорт типов. Экспорт получается скрытым,если в модуле определений описано просто имя типа: в этом случае детали описания скрыты вмодуле реализации. Скрытый экспорт возможен только для указательного типа. Этот тип, однако,весьма важен потому, что указательный тип подчинен другому типу (обычно записи), которыйможет быть скрыт. Далее следуют примеры, иллюстрирующие упрятывание деталей описаниятипов, известное также под названием "абстракции данных".Следующий простой пример проясняет существенные свойства модулей, хотя обычномодули - значительно большие фрагменты программы, и они содержат более длинный списокописаний.
В этом примере экспортируются две процедуры занести и взять, соответственнодобавляющие в буфер и извлекающие из него данные, причем сам буфер скрыт. Фактическидоступ к буферу может осуществляться только через эти две процедуры, и, следовательно, можетбыть гарантировано его надлежащее функционирование.DEFINITION MODULE Буфер;VAR непуст,неполон: BOOLEAN;PROCEDURE занести(х: CARDINAL);PROCEDURE взять(VAR x: CARDINAL);END Буфер.Этот раздел определений содержит всю информацию о буфере, которую, какпредполагается, должен знать пользователь модуля. Детали его Функционирования, егореализации содержатся в соответствующем модуле реализации.IMPLEMENTATION MODULE Буфер;CONST N = 100;VAR in,out: [0..N-1];n: [0..N];буф: ARRAY [0..N-1] OF CARDINAL;81PROCEDURE занести(х: CARDINAL);BEGINIF n < N THENбуф[in] := x: in := (in+1) MOD N;n := n + 1; неполон := n < N; непуст := TRUEENDEND занести;PROCEDURE взять(х: CARDINAL);BEGINIF n > 0 THENx := буф[out]; out := (out+1) MOD N;n := n - 1; непуст := n > 0; неполон := TRUEENDEND взять;BEGIN (*инициализация*)n := 0; in : = 0; out := 0;непуст := FALSE; неполон := TRUEEND Буфер.Этот пример реализует дисциплину очереди (первым пришел - первым обслужен).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
