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

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

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

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

Терминология [ править ]

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

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

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

Языковая поддержка [ править ]

Языки, формально поддерживающие концепцию модуля, включают Ada , Algol , BlitzMax , C ++ , C # , Clojure , COBOL , Common_Lisp , D , Dart , eC , Erlang , Elixir , Elm , F , F # , Fortran , Go , Haskell , IBM / 360 Assembler. , Язык управления (CL), IBM RPG , Java, ^[a] MATLAB , ML , Modula , Modula-2 , Modula-3 , Morpho, NEWP , Oberon , Oberon-2 , Objective-C , OCaml , несколько производных от Pascal ( Component Pascal , Object Pascal , Turbo Pascal , UCSD Pascal ), Perl , PL / I , PureBasic , Python , R , Ruby , ^[2] Rust ,JavaScript , ^[3] Visual Basic .NET и WebDNA .

Яркими примерами языков, которые не поддерживают модули, являются C , C ++ и Pascal в их исходной форме , однако C и C ++ позволяют указывать отдельные интерфейсы компиляции и декларативные интерфейсы с помощью файлов заголовков . Модули были добавлены в Objective-C в iOS 7 (2013); на C ++ с C ++ 20 , ^[4] и Pascal был заменен Modula и Oberon, которые включали модули с самого начала, и различные производные, которые включали модули. В JavaScript есть собственные модули с ECMAScript 2015.

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

Ключевые аспекты [ править ]

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

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

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

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

История [ править ]

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

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

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

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

См. Также [ править ]

• Язык описания архитектуры
• Сплоченность (информатика)
• Компонентная разработка программного обеспечения
• Закон Конвея
• Связь (информатика)
• Давид Парнас
• Скрытие информации (инкапсуляция)
• Библиотека (вычислительная)
• Список атрибутов качества системы
• Модульная конструкция
• Плагин (вычисления)
• Фрагмент (программирование)
• Структурированный анализ
• Структурированное программирование

Заметки [ править ]

Ссылки [ править ]

Внешние ссылки [ править ]

• Как разложить систему на модули
• Платформа SMC