Что такое модуль в программировании

Модульное программирование

Модуль – это последовательность логически связанных фрагментов, оформленных как отдельная часть программы.

К модулю предъявляются следующие требования:

1) модуль должен реализовывать единственную функцию, т.е. при построении модуля используется концепция: «один модуль – одна функция». Таким образом, модуль – это элемент программы, выполняющий самостоятельную задачу. На его входе он может получать определенный набор исходных данных, обрабатывать их в соответствии с заданным алгоритмом и возвращать результат обработки, т.е. реализуется стандартный принцип IPO (Input – Process – Output) – вход-процесс-выход;

2) на модуль нужно ссылаться с помощью его имени. Он должен иметь один вход и один выход, что гарантирует замкнутость модуля и упрощает сопровождение программ;

3) модуль должен иметь функциональную завершенность, т.е. выполнять перечень регламентированных операций для реализации каждой отдельной функции в полном составе, достаточных для завершения начатой обработки;

4) модуль должен возвращать управление в точку его вызова, в свою очередь, он должен иметь возможность сам вызывать другие модули;

5) модуль не должен сохранять историю своих вызовов и использовать ее при своем функционировании;

6) модуль должен иметь логическую независимость, т.е. результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;

7) модуль должен иметь слабые информационные связи с другими программными модулями – обмен информацией между модулями должен быть по возможности минимизирован;

8) модуль должен быть сравнительно невелик, т.е. быть обозримым по размеру и сложности. Опытные программисты рекомендуют его размер не более двух страниц распечатки на принтере.

Для достижения независимости модулей часто используется принцип информационной локализованности, который состоит в том, что вся информация о структуре данных, о прототипах функций, констант и т.д. сосредотачивается («упрятывается») в отдельном модуле. Доступ к этой информации осуществляется только через этот модуль (в алгоритмическом языке С/С++ такие модули имеют расширение *.h).

Программирование с использованием модулей называется модульным программированием. Оно возникло еще в начале 60-х годов XX в. Модульное программирование основано на идее использования уровней абстракции, когда вся проблема или комплекс задач разбивается на задачи, подзадачи, абстрагируется и представляется в виде иерархического дерева связанных между собой модулей, в совокупности представляющих создаваемое программное обеспечение (ПО).

Достоинствами модульного программирования является следующее:

· большую программу могут писать одновременно несколько программистов, что позволяет раньше закончить задачу;

· можно создавать библиотеки наиболее употребительных модулей;

· упрощается процедура загрузки в оперативную память большой программы, требующей сегментации;

· появляется много естественных контрольных точек для отладки проекта;

· проще проектировать и в дальнейшем модифицировать программы.

Недостатки модульного программирования заключаеются в следующем:

· возрастает размер требуемой оперативной памяти;

· увеличивается время компиляции и загрузки;

· увеличивается время выполнения программы;

· довольно сложными становятся межмодульные интерфейсы.

Модульное программирование реализуется через модули – функции. Функция – это область памяти, выделяемая для сохранения программного кода, предназначенного для выполнения конкретной задачи. Другими словами, функция – минимальный исполняемый модуль программы на языке С/С++. По умолчанию функция имеет тип external, и доступ к ней возможен из любого файла программы. Но она может быть ограничена спецификатором класса памяти static.

Функция характеризуется типом, областью действия связанного с функцией имени, видимостью имени функции, типом связывания.

Все функции имеют рекомендуемый стандартами языка единый формат определения. Он имеет заголовок функции, в котором задаются: тип, имя функции и спецификация формальных параметров:

Тип имя_функции (спецификация_параметров) тело_функции

Тип – это тип возвращаемого функцией значения, в том числе void (кроме типов массива или функции). Умолчанием является тип int. Если тип возврата функции не void, то тело функции должно содержать как минимум один оператор return.

Имя_функции – идентификатор, с помощью которого можно обратиться к функции. Он выбирается программистом произвольно и не должен совпадать со служебными словами и с именами других объектов программы. Однако любая программа на языке С/С++ должна иметь хотя бы одну функцию с именем main – главную функцию, содержащую точку входа в программу.

Спецификация_параметров – список формальных параметров, т.е. переменных, принимающих значения, передаваемые функции при ее вызове. Список формальных параметров перечисляется через запятую. Каждый формальный параметр должен иметь следующий формат:

Тип может быть встроенным (int, long, float, double и т.д.), структурой (struct), объединением (union), перечислением (enum), указателями на них или на функции или классы (class). Имя_формального_параметра представляет собой имя используемой в теле функции переменной. Идентификаторы формальных параметров не могут совпадать с именами локальных переменных, объявленных внутри тела функции.

Объявление формального параметра может содержать инициализатор, то есть выражение, которое должно обеспечить параметру присвоение начального значения. Инициализатор параметра не является константным выражением. Начальная инициализация параметров происходит не на стадии компиляции (как, например, выделение памяти под массивы), а непосредственно в ходе выполнения программы.

В языке С/C++ допустимы функции, количество параметров у которых при компиляции функции не фиксировано, следовательно, остаются неизвестными и их типы. Количество и типы параметров таких функций становятся известными только при их вызове, когда явно задан список фактических параметров. При определении и описании таких функций со списками параметров неопределенной длины спецификацию формальных параметров следует закончить запятой и многоточием.

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

Спецификация_параметровможет отсутствовать, то есть скобки могут быть пустыми, но в этом случае рекомендуется указывать тип void.

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

Модуль (программирование)

Модуль — функционально законченный фрагмент программы, оформленный в виде отдельного файла с исходным кодом или поименованной непрерывной её части (например, Active Oberon), предназначенный для использования в других программах. Модули позволяют разбивать сложные задачи на более мелкие в соответствии с принципом модульности. Обычно проектируются таким образом, чтобы предоставлять программистам удобную для многократного использования функциональность (интерфейс) в виде набора функций, классов, констант. Модули могут объединяться в пакеты и, далее, в библиотеки. Удобство использования модульной архитектуры заключается в возможности обновления (замены) модуля, без необходимости изменения остальной системы. В большинстве случаев различные модули могут запускаться как на одном сервере, так и на разных, для распределения нагрузки и создания распределенной архитектуры.

История концепции модулей

История концепции модулей, как единиц компиляции, восходит к языкам Фортран II и Кобол, то есть к концу 1950-х годов [1] [2] . В 1976 году появилась публикация, в которой была развита концепция модульности — о языке Mesa (англ.), который был разработан в Xerox PARC. В 1977 году подробно ознакомился с этой концепцией ученый Никлаус Вирт, общаясь с разработчиками в Xerox PARC. [3] Эти идеи были использованы Виртом при создании языка Модула-2, публикация о котором вышла в 1977 году [4] .

Поддерживающие языки

Языки формально поддерживающие концепцию модулей: IBM S/360 Assembler, Кобол, RPG, ПЛ/1, Ада, D, F (англ.) , Фортран, Haskell, Blitz BASIC, OCaml, Паскаль, ML, Модула-2, Оберон, Компонентный Паскаль, Zonnon, Erlang, Perl, Python и Ruby. В IBM System i использовались «модули» от языков RPG, Кобол и CL, когда программировалась в среде ILE.

Модульное программирование может быть осуществлено, даже когда синтаксис языка программирования не поддерживает явное задание имён модулям.

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

Примечания

↑A brief history of FORTRAN
↑COBOL Subprograms
↑Никлаус Вирт. Краткая история Modula и Lilith, перевод с англ. с комментариями в тексте Р. Богатырева
↑The History of Modula-2 and Oberon

Wikimedia Foundation . 2010 .

Смотреть что такое «Модуль (программирование)» в других словарях:

Модуль — (от лат. modulus «маленькая мера»): В Викисловаре есть статья «модуль» Мо … Википедия

Модуль (значения) — Модуль (от лат. modulus «маленькая мера») составная часть, отделимая или хотя бы мысленно выделяемая из общего. Модульной обычно называют вещь, состоящую из чётко выраженных частей, которые нередко можно убирать или добавлять, не разрушая вещь… … Википедия

Контрактное программирование — (design by contract (DbC), programming by contract, contract based programming) это метод проектирования программного обеспечения. Он предполагает, что проектировщик должен определить формальные, точные и верифицируемые спецификации… … Википедия

Связанность (программирование) — Связанность (англ. coupling) или зависимость (англ. dependency) характеристика взаимосвязи модуля с другими модулями. Это степень, в которой каждый программный модуль полагается на другие модули. Связанность обычно… … Википедия

Функциональное программирование на Питоне — Функциональное программирование является одной из парадигм, поддерживаемых языком программирования Python. Основными предпосылками для полноценного функционального программирования в Python являются: функции высших порядков, развитые средства… … Википедия

Функциональное программирование на Python — Функциональное программирование является одной из парадигм, поддерживаемых языком программирования Python. Основными предпосылками для полноценного функционального программирования в Python являются: функции высших порядков, развитые средства… … Википедия

Читать еще: Встраиваемые языки программирования

Объектно-ориентированное программирование на Python — Объектно ориентированное программирование на Python программирование на Python с использованием парадигмы ООП: с самого начала Python проектировался как объектно ориентированный язык программирования[1]. Содержание 1 Введение 1.1 … Википедия

Аспектно-ориентированное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Эволюционное программирование — Содержание 1 Эволюционное программирование 2 Современное эволюционное программирование … Википедия

Компонентно-ориентированное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Модульное программирование

Цели урока:

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

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

1.1. Устный опрос:

Какой вид имеет структура описания процедуры и функции в Turbo Pascal?
В чем состоит отличие описания процедуры и функции?
Что такое область действия идентификаторов?
Какие параметры называются формальными и какие фактическими?
Какие способы передачи параметров реализованы в Turbo Pascal?
Почему при работе с графикой в Turbo Pascal необходимо предложение uses Graph?
Какие процедуры и функции модуля Graph вам известны?

2. Изложение нового материала.

2.1. Содержание и последовательность излагаемых учебных вопросов.

2.1.1. Технология модульного программирования.

Языки высокого уровня появились в 60-е годы. Ресурсы ЭВМ (объем ОЗУ 8 Кбайт, быстродействие 20 тыс. операций в сек.) были недостаточны, поэтому программисты вынуждены были писать программы весьма “хитроумно” с использованием оператора безусловного перехода. Программа получалась запутанной, имела структуру “блюдо спагетти”. Так как область применения ЭВМ расширялась, программное обеспечение усложнялось. Программисты, решающие сложные задачи, столкнулись с проблемой разрастания количества и размера программ до такой степени, что дальнейший процесс разработки становился практически неуправляемым, и никто из разработчиков не мог с уверенностью сказать, что созданный программный продукт всегда выполняет то, что требуется, и что он не выполняет ничего такого, что не требуется. Поэтому возникла необходимость в новой методологии разработки программных проектов. В 1968–1969 гг. состоялись конференции по программированию. На второй из них Эдсгер Дийкстра предложил принципиально новый способ создания прграмм – структурное программирование. Главное – разбиение программного комплекса (при его создании) на программные модули, которые соединяются иерархически.

Цели модульного программирования:

1. Улучшать читабельность программ.
2. Повышать эффективность и надежность программ (легко находить и корректировать ошибки).
3. Уменьшать время и стоимость программной разработки (уменьшается время отладки).

Разбиение программного комплекса на модули выполняется в соответствии со следующими принципами:

Модуль – это независимый блок, код которого физически и логически отделен от кода других модулей.
Размер модуля не больше 100 операторов.
Имеет одну входную и одну выходную точку.
Модули связаны иерархически.
Разбиение должно обеспечивать надежное скрытие информации в модуле.
Парнас: “Для написания одного модуля должно быть достаточно минимальных знаний о тексте другого”.
Каждый модуль должен начинаться с комментария (его назначение – входные и выходные переменные).
Не использовать метки и оператор GOTO.
Использовать только стандартные управляющие конструкции (условие, выбор, цикл, блок).

2.1.2. Нисходящее и восходящее программирование.

При разработке модульных программ применяются два метода проектирования – нисходящее и восходящее. При нисходящем проектировании разработка программного комплекса идет сверху вниз.

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

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

Недостатки нисходящего проектирования:

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

Преимущество нисходящего проектирования – на самом начальном этапе проектирования отлаживается головной модуль (логика программы).

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

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

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

2.1.3. Оформление программы в виде модуля.

При подключении стандартных модулей достаточно корректно записать их идентификаторы в предложении uses. При разработке собственных модулей необходимо помнить некоторые особенности:

Не допускается одновременное использование модулей с одинаковыми именами.
Идентификатор модуля, указанный в заголовке (unit), должен совпадать с именами файлов, содержащих исходный (.pas) (.tpu, . tpp, .tpw) код.
Если идентификатор модуля длиннее восьми символов, то он должен совпадать с именами файлов по первым восьми символам.

Общая структура модуля

unit идентификатор модуля;

<Интерфейсный раздел>

в этом разделе описывается взаимодействие данного модуля с другими пользовательскими и стандартными модулями, а также с главной программой. Другими словами – взаимодействие модуля с “внешним миром”.

Список импорта интерфейсного раздела

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

Список экспорта интерфейсного раздела

const
type
var
procedure
function

Раздел реализации

в этом разделе указывается реализационная (личная) часть описаний данного модуля, которая недоступна для других модулей и программ. Другими словами – “внутренняя кухня модуля”.

Список импорта раздела реализации

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

Подразделы внутренних для модуля описаний

В этих подразделах описываются метки, константы, типы, переменные, процедуры и функции, которые описывают алгоритмические действия, выполняемые данным модулем, и которые являются “личной собственностью” только данного модуля. Эти описания недоступны ни одному другому модулю. Заголовки процедур и функций в этом подразделе допускается указывать без списка формальных параметров. Если заголовки указаны все же с параметрами, то список формальных параметров должен быть идентичен такому же списку для соответствующей процедуры (функции) в разделе interface.

label
const
type
var
procedure
function

Раздел инициализации

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

Пример модуля a1

unit a1;
interface
uses graph;
procedure init;
procedure pr1;
implementation
procedure init;

procedure pr1;
begin

end;
begin
init;
pr1;
readln;
end.

Головной модуль

program a;
uses a1, a2, a3, a4;
begin
pr1;
pr2;
pr3;
pr4;
readln;
end.

3. Проверка качества усвоения нового материала.

3.1. Устный опрос.

Назовите принципы модульного программирования.
Когда применяется технология нисходящего программирования? А восходящего?
В чем различие между технологией восходящего и технологией нисходящего программирования?
Какие существуют особенности при разработке собственных модулей?
Из каких разделов состоит модуль?
Что описывается в разделе interface?
Что описывается в разделе implementation?
Что описывается в разделе инициализации?

3.2. Самостоятельная работа учащихся на уроке.

Учащиеся разбиты на две группы. Работой каждой группы руководит “начальник”. Получив задание, учащиеся начинают коллективную работу. Каждый ученик разрабатывает свою программу, оформляет ее в виде модуля UNIT и отдает “начальнику”, который пишет головную программу, объединяя модули своих “подчиненных”.

Литература:

Марченко А. И., Марченко Л. М. “Программирование в среде Turbo Pascal 7.0”, М.: “Бином Универсал”, 1998.
Информатика. № 2. /Приложение к газете “Первое сентября”, 1996.

Что такое модульное программирование и кому оно нужно

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

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

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

Классическая проблема программирования

В западной литературе существует термин «big ball of mud» для описания архитектуры программы. Давайте переведём его дословно. Графически «большой шар грязи» можно представить в виде точек на окружности, символизирующих функциональные элементы, и прямых – связей между ними:

Похоже на ваши глаза перед сдачей проекта, не так ли?

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

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

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

В этом случае полезнее обратиться к модулям. Модуль – логически завершённый фрагмент кода, имеющий конкретное функциональное назначение. Для взаимодействия модулей используются способы, не позволяющие изменять параметры и функциональность. Плюсы модульного программирования очевидны:

Ускорение разработки.
Повышение надёжности.
Упрощение тестирования.
Взаимозаменяемость.

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

Но не всё так просто.

Проблемы модульного программирования

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

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

В модульном программировании существует три основные реализации:

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

Несмотря на то, что первая реализация IoC используется чаще всего, для первых шагов в модульном программировании лучше использовать другие два. Причина – простое создание интерфейсов лишь ограничивает доступ к модулям, а для снижения сложности кода необходимо также уменьшить количество связей. Интерфейсы, хаотично ссылающиеся на другие интерфейсы, код только усложняют.

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

Таким образом, поддержка принципов модульного программирования, инверсии управления и четкой архитектуры приложения поможет убить сразу трёх зайцев:

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

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

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

Классическая проблема программирования

Похоже на ваши глаза перед сдачей проекта, не так ли?

Ускорение разработки.
Повышение надёжности.
Упрощение тестирования.
Взаимозаменяемость.

Но не всё так просто.

Проблемы модульного программирования

В модульном программировании существует три основные реализации:

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

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

Модульное программирование — Modular programming

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

Интерфейс модуля выражает элементы, которые предусмотрены и требуемые модуль. Элементы , определенные в интерфейсе могут быть обнаружены другими модулями. Реализация содержит рабочий код , который соответствует элементам , объявленных в интерфейсе. Модульное программирование тесно связано с структурного программирования и объектно-ориентированного программирования , все с той же целью содействия строительству крупных программ и систем путем разложения на более мелкие куски, и все происходящие вокруг 1960 — х годов. В то время как историческое использование этих терминов противоречиво, «модульное программирование» относится теперь к разложению высокого уровня кода целой программы на часть: Структурное программирование для использования коды низкоуровневой структурированного потока управления , а также объектно-ориентированный программирование на данных использования объектов , своего рода структуры данных .

В объектно-ориентированном программировании, использование интерфейсов в качестве архитектурного шаблона для построения модулей известно как интерфейс программирования на основе .

содержание

терминология

Термин сборки (как в .NET языках , как C # , F # или Visual Basic .NET ) или пакет (как в Dart , Go или Java ) иногда используется вместо модуля . В других реализациях, это понятие принципиально отличается; в Python пакет представляет собой набор модулей, в то время как в Java- введение новой концепции модуля (сборник пакетов с улучшенным контролем доступа) планируются.

Кроме того, термин «пакет» имеет другое применение в программном обеспечении (например , пакеты .NET NuGet ). Компонент представляет собой аналогичную концепцию, но , как правило , относится к более высокому уровню; компонент является частью целой системы , в то время как модуль является частью индивидуальной программы. Масштаб термина «модуль» существенно различается между языками; в Python очень мелкосерийное и каждый файл представляет собой модуль, в то время как в Java 9 планируется быть крупномасштабными, где модуль представляет собой набор пакетов, которые в свою очередь , коллекции файлов.

Другие термины для модулей включают в себя блок , используемый в Pascal диалектах.

Языковая поддержка

Заметные примеры языков , которые не имеют поддержки модулей C , C ++ и Pascal (в его исходной форме). По состоянию на 2014 год , модули были предложены для C ++; модули были добавлены в Objective-C в IOS , 7 (2013 г. ); и Паскаль был заменен Modula и Oberon, который включал модули с самого начала, а также различные производные , которые включены модули. JavaScript была родных модулей так ECMAScript 2015.

Модульное программирование может выполняться , даже если язык программирования не хватает явных синтаксических функций для поддержки названных модулей, как, например, в С. Это делается за счет использования существующих возможностей языка, а также , например, кодирование конвенций , программирования идиомы и физические структура кода. IBM System я также использует модули при программировании в Integrated Language Environment (ILE).

Ключевые аспекты

С модульным программированием, проблемы разделены таким образом, что модули выполняют логически дискретные функции, взаимодействующие через четко определенные интерфейсы. Часто модули образуют ориентированный ациклический граф (DAG); в этом случае циклическая зависимость между модулями рассматриваются как указывающие , что они должны быть один модулем. В случае , когда модули действительно образуют DAG они могут быть организованы в виде иерархии, где модули низшего уровня являются независимыми, в зависимости от каких — либо других модулей, и модули более высокого уровня , зависит от них более низкого уровня. Особая программа или библиотека представляет собой модуль верхнего уровня иерархии своей собственной, но может , в свою очередь , можно рассматривать как модуль нижнего уровня программы более высокий уровня, библиотеку или систему.

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

Это делает модульную конструкцию системы, если правильно построить, гораздо более многоразовые , чем традиционные монолитные конструкции, так как все (или многие) из этих модулей могут быть затем повторно (без изменений) в других проектах. Это также облегчает «разрушение» проектов на несколько более мелких проектов. Теоретически, модульный программный проект будет более легко собрать большие командами, поскольку ни один из членов команды не создавать всю систему, или даже нужно знать о системе в целом. Они могут быть направлены только на назначенном меньшую задачу (это, как утверждается, счетчики ключевое предположение о Мифический человеко — месяц , делая это на самом деле можно добавить больше разработчиков к концу программного проекта , не делая его еще позже).

история

Модульное программирование в виде подсистем ( в частности , для I / O) библиотек программного обеспечения и, относится к ранним системам программного обеспечения, где она была использована для повторного использования кода . Модульное программирование сами по себе, с целью модульности, разработанной в конце 1960 — х и 1970 — х года, как более масштабного аналог концепции структурного программирования (1960). Термин «модульное программирование» относится , по крайней мере национальный симпозиум по модульному программированию, организованном в информации и систем Институте в июле 1968 года Ларри Константином ; другие ключевые понятия были скрытие информации (1972) и разделение интересов (SoC, 1974).

Модули , не были включены в оригинальной спецификации для Алгола 68 (1968), но были включены в качестве расширений в ранних реализациях, Алгол 68-R (1970) и Алгол 68C (1970), а позднее формализованы. Одним из первых языков , разработанных с самого начала для модульного программирования был недолгим Modula (1975), по Никлаус Вирт . Другой ранний модульный язык был Mesa (1970 — е годы), по Xerox PARC , и Вирт опиралась на Mesa, а также оригинальной Modula в его преемника, Modula-2 (1978), что повлияло на более поздние языки, в частности , через его преемника, Modula-3 ( 1980 — е годы). Использование Modula по dot- уточненных имен , любят M.a ссылаться на объект a из модуля M совпадает с обозначениями , чтобы получить доступ к области записи (и аналогично для атрибутов или методов объектов), и в настоящее время широко распространены, видели в C #, Dart, Go, Java и Python, среди других. Модульное программирование стало широко распространенным из 1980 — х годов: оригинальный Pascal язык (1970) , не включают в себя модули, но более поздние версии, в частности , UCSD Pascal (1978) и Turbo Pascal (1983) включил их в виде «единиц», как это сделал Паскаль -influenced Ада (1980). Extended Pascal ISO 10206: 1990 стандарт хранится ближе к Модуле-2 в своей модульной поддержке. Standard ML (1984) имеет один из самых полных модульных систем, в том числе функторов (параметризованных модулей) для сопоставления между модулями.

В 1980 — х и 1990 — х годах, модульного программирования был омрачен и часто сплавлены с объектно-ориентированного программирования , в частности , из — за популярности C ++ и Java. Например, семейство C языков была поддержка объектов и классов в C ++ (первоначально C с классами , 1980) и Objective-C (1983), которые поддерживают только модули 30 лет или более поздними. Java (1995) поддерживает модули в виде пакетов, хотя основной единицей организации кода является классом. Тем не менее, в Python (1991) заметно использовал как модули и объекты с самого начала, используя модули в качестве основного блока организации коды и «пакеты» в качестве более масштабного блока; и Perl , 5 (1994) включает в себя поддержку для обоих модулей и объектов, с широким набором модулей будут доступны из CPAN (1993).

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