вы можете увидеть модуль, библиотеку и фреймворк таким образом:

• модуль = ваши пальцы
• библиотека = руки
• база = ваше тело

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

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

Ваше тело / основа:
Ваше тело-это целостная система, вы можете делать со своим телом все, что хотите (даже летать, просто войти в самолет, и там вы идете, самолет-это другая система), вы уникальны... а рамки это ваше тело, полная система,он не работает для себя (вам нужно кодировать herpderp) но вы можете сделать полную программы взлома работает...

просто моя интерпретация... если я ошибаюсь, пожалуйста, исправьте меня.

моя художественная интерпретация ASCII того, что я понял из других ответов:

+-----------------------------------------------+
|  ...........................  ..............  |
|  : f1() f2()  :  f3()      :  : f4() f5()  :  |
|  :            :            :  :            :  |
|  : l1_module1 : l1_module2 :  : l2_module3 :  |
|  :            :            :  :            :  |
|  --library1-----------------  --library2----  |
|                                               |
|   application.c                               |
|                                               |
|       #include l1_module2                     |
|       #include l2_module3                     |
|                                               |
|       int main() {                            |
|           # case 'reload'                     |
|           f5();                               |
|           # case 'start'                      |
|           f1();                               |
|           # case 'stop'                       |
|           f4();                               |
|       }                                       |
|                                               |
+-----------------------------------------------+

.................................................
: FRAMEWORK_X                                   :
:                                               :
:     application start                         :
:     ...                                       :
:     application reload                        :
:     application stop                          :
:     ...                                       :
:...............................................:

что будет:

1. разработчик устанавливает library1 и library2 так что они могут использовать функции внутри этих модулей.

2. затем они включают l1_module1 и l2_module3. (Они не нужны l1_module2 на данный момент).

3. теперь они могут использовать функциональность f1,f2,f4 и f5, Поэтому они пишут свое заявление.

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

некоторые замечания:

• на практике есть всегда какие-то рамки. Например, ОС является основой для вашего приложения (именно поэтому вы определяете main())! Или вы могли бы сказать, что загрузчик является основой для вашей ОС и BIOS-это фреймворк для вашего загрузчика и т. д.

грубо говоря, я бы рассмотрел это следующим образом: модуль является импортируемым "атомом" функциональности; он определяет наименьшее подмножество сгруппированных функций, которые могут быть использованы (обратите внимание, что это не самая маленькая единица функциональности; это будет класс (или функция, в зависимости)). Библиотека в этом подходе будет представлять собой набор модулей; вы можете использовать библиотеку, не используя все модули, которые являются частью этой библиотеки. Фреймворк-это среда, от которой зависит библиотека (вероятно); он делает до базовой среды, в которой все вышеперечисленное работает.

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

С моей точки зрения a framework содержит libraries и как modules.

Е. Г. В Свифт a module является единицей распределения кода-a framework или приложение, которое строится и поставляется как единое целое.

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

модуль

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

в контексте модульное Программирование, модуль-это сущность, выражаемая языком кодирования, вводящая программируемость (обычно язык программирования или язык описания оборудования) в решение.

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

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

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

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

библиотека

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

рамки

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

поскольку нет никакого "официального" и консенсуса по этой теме, вот мое предложение. ИМО описание должно быть коротким и простым (поцелуй).

библиотека: Коллекция пространства имен / модульного кода, вызываемого разработчиком.

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

I think the term framework is way to often used by developers (for whatever reason) to describe some design patterns within an application. I mean IMO it should not have 2 definitions.

модуль: Например в JavaScript модуль-это просто объект с публичными свойствами. ИМО его можно использовать взаимозаменяемо с термином библиотека.