Самое важное отличие, и на самом деле определяющее различие между библиотекой и каркасом – это инверсия управления .

Что это значит? Ну, это означает, что когда вы звоните в библиотеку, вы контролируете ситуацию. Но с каркасом элемент управления инвертируется: фреймворк вызывает вас. (Это называется Голливудским принципом: не называйте нас, мы позвоним вам.) Это в значительной степени определение frameworks. Если у него нет инверсии управления, это не фреймворк. (Я смотрю на вас, .NET!)

В принципе, весь stream управления уже находится в рамках, и есть только несколько предопределенных белых пятен, которые вы можете заполнить своим кодом.

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

Я не знаю, действительно ли терминологический набор инструментов хорошо определен. Просто слово «комплект», похоже, предлагает некоторую модульность, то есть набор независимых библиотек, которые вы можете выбрать и выбрать. Что же тогда делает набор инструментов отличным от нескольких независимых библиотек? Интеграция: если у вас просто куча независимых библиотек, нет никакой гарантии, что они будут хорошо работать вместе, тогда как библиотеки в наборе инструментов были разработаны для совместной работы – вам просто не нужно использовать их все .

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

Мартин Фаулер обсуждает разницу между библиотекой и структурой в своей статье « Инверсия управления» :

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

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

Подводя итог: ваш код вызывает библиотеку, но фреймворк вызывает ваш код.

Введение

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

Библиотека

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

Инструментарий

Исторически, инструментарий представляет собой более сосредоточенную библиотеку с определенной и конкретной целью. В настоящее время этот термин вышел из употребления и используется почти исключительно (по общему мнению автора) для графических виджетов и компонентов графического интерфейса в текущую эпоху. Инструментарий чаще всего будет работать на более высоком уровне абстракции, чем в библиотеке, и часто будет потреблять и использовать библиотеки. В отличие от библиотек, код инструментария часто используется для выполнения задачи клиентского кода, например, для создания windows, изменения размера windows и т. Д. Более низкие уровни абстракции в наборе инструментов являются либо фиксированными, либо могут управляться самим клиентом кода в запрещенном виде. (Стиль Think Window, который может быть исправлен или который может быть изменен заранее по клиентскому коду).

Фреймворк

Исторически сложилось, что основой был набор взаимосвязанных библиотек и модhive, которые были разделены на категории «Общие» или «Конкретные». Общие frameworks должны были предлагать комплексную и интегрированную платформу для создания приложений, предлагая общие функции, такие как управление памятью через платформу, многоstreamовые абстракции, динамические структуры (и общие структуры в целом). Исторические общие frameworks (без инъекций зависимостей, см. Ниже) почти повсеместно заменялись полиморфными шаблонами (параметризованными) пакетами языковых предложений в языках OO, такими как STL для C ++ или в упакованных библиотеках для языков, отличных от OO (гарантированные заголовки Solaris C ). Общие frameworks, работающие на разных уровнях абстракции, но повсеместно низкие уровни, и подобные библиотеки полагались на код клиента, выполняющий его конкретные задачи с их помощью.

«Конкретные» структуры были исторически разработаны для одиночных (но часто разрастающихся) задач, таких как системы «Command and Control» для промышленных систем и ранних сетевых стеков, и работали на высоком уровне абстракции и, как и инструментальные средства, использовались для выполнения задач клиентских кодов.

В настоящее время определение структуры более сосредоточено и взято по принципу «инверсия контроля», как упоминалось в другом месте в качестве руководящего принципа, поэтому программный stream, а также исполнение осуществляется каркасом. Однако frameworks все же нацелены либо на конкретный результат; приложение для конкретной ОС (например, MFC для MS Windows) или для более общей работы (например, Spring framework).

SDK: «Комплект разработки программного обеспечения»

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

двигатель

Двигатель (в терминах ввода кода) представляет собой двоичный код, который каким-то образом будет запускать на заказ содержимое или входные данные процесса. Игровые и графические двигатели, пожалуй, являются самыми предвестниками этого термина и почти повсеместно используются с SDK для нацеливания самого движка, такого как UDK (Unreal Development Kit), но существуют и другие двигатели, такие как поисковые системы и двигатели РСУБД ,

Двигатель часто, но не всегда, позволяет доступным только своим внутренним частям для своих клиентов. Чаще всего для того, чтобы ориентироваться на другую архитектуру, изменяйте представление вывода двигателя или настройки. Двигатели с открытым исходным кодом по определению открываются для клиентов, которые меняются и изменяются по мере необходимости, а некоторые притягательные механизмы полностью фиксируются. Однако наиболее часто используемые двигатели в мире – это, безусловно, Javascript Engines. Встроенный в каждый браузер везде, есть целый ряд движков JavaScript, которые будут принимать javascript как входные данные, обрабатывать его, а затем выводить на визуализацию.

API: «Интерфейс прикладного программирования»

Последний вопрос, который я отвечаю, является моим личным жуком: API, исторически использовался для описания внешнего интерфейса приложения или среды, который сам мог самостоятельно работать или, по крайней мере, выполнять свои задачи без какого-либо необходимого вмешательства клиента после первоначального исполнения. Такие приложения, как базы данных, текстовые процессоры и системы Windows, будут подвергать фиксированный набор внутренних перехватов или объектов внешнему интерфейсу, который клиент мог бы затем вызвать / изменить / использовать и т. Д., Чтобы выполнять возможности, которые может выполнять оригинальное приложение. API отличается от того, сколько функций было доступно через API, а также, сколько основного приложения было (повторно) использовано кодом клиента. (Например, API обработки текстов может потребовать, чтобы полное приложение загружалось в фоновом режиме, когда запускался каждый экземпляр клиентского кода или, возможно, только одна из его связанных библиотек, тогда как работающая оконная система создавала бы внутренние объекты, которые будут управляться сами по себе и вместо этого используйте обратные дескрипторы клиентского кода.

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

замечание

Как отмечалось выше, исторические и текущие определения вышеуказанных терминов сдвинуты, и это, как видно, сводится к достижениям в научном понимании основополагающих принципов и парадигм вычислений, а также вплоть до появления конкретных моделей программного обеспечения. В частности, системы GUI и Windowing в начале девяностых помогли определить многие из этих терминов, но так как эффективная гибридизация OS Kernel и Windowing для массовых операционных систем cunsumer (возможно, Linux) и массовое внедрение инъекции / инверсия управления как механизма потребления библиотек и фреймворков, эти термины должны были изменить их соответствующие значения.

PS (Год спустя)

После тщательного изучения этого вопроса более года я отвергаю принцип IoC как определяющее различие между каркасом и библиотекой. Есть большое количество популярных авторов, которые говорят, что это так, но есть почти равное количество людей, которые говорят, что это не так. Существует слишком много «рамок», которые НЕ используют IoC, чтобы сказать, что это определяющий принцип. Поиск встроенных или микроcontrollerов позволяет выявить целое множество, которые НЕ используют IoC, и теперь я считаю, что язык .Net и CLR является приемлемым потомком «общей» структуры. Сказать, что IoC является определяющей характеристикой, просто слишком жестко для меня, чтобы принять, что я боюсь, и отвергает из рук все, что ставит себя вперед в качестве frameworks, которая соответствует историческому представлению, как упомянуто выше.

Для получения подробной информации о структурах, отличных от IoC, см., Как уже упоминалось выше, многие встроенные и микроархивы, а также любые исторические frameworks на языке, который не обеспечивает обратный вызов через язык (ОК. Обратные вызовы могут быть взломаны для любого устройства с современным , но не средним программистом) и, очевидно, инфраструктурой .net.

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

При написании кода:

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

Вообще говоря, это полностью объясняет различия между терминами.

схема

Если вы более визуальный ученик, вот диаграмма, которая делает ее более ясной:

(Кредиты: http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks )

Библиотека – это просто набор методов / функций, завернутых в пакет, который можно импортировать в проект кода и повторно использовать.

Структура представляет собой надежную библиотеку или коллекцию библиотек, которая обеспечивает «основу» для вашего кода. Каркас следует за шаблоном инверсии управления. Например, .NET framework представляет собой большую коллекцию связных библиотек, в которой вы создаете приложение поверх него. Вы можете утверждать, что между каркасом и библиотекой нет большой разницы, но когда люди говорят, что «каркас» обычно подразумевает больший, более надежный набор библиотек, которые будут играть неотъемлемую часть приложения.

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

Они почти все могут использоваться взаимозаменяемо.

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

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

Библиотека

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

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

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

Инструментарий

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

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

SDK – это, как правило, инструментарий, в котором они пытаются объединить набор инструментов (часто нескольких типов) в один пакет.

Я думаю, что общий stream – это то, что инструмент что-то делает для вас, либо полностью, либо помогает вам это сделать. Инструментарий – это просто набор инструментов, которые выполняют или помогают выполнять определенный набор действий.

Фреймворк

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

Это означает, что вы создаете свой код против фреймворка, тогда как вы создаете библиотеку против вашего кода.

Но, кажется, иногда слово framework используется в том же смысле, что и инструментарий или даже библиотека. .Net Framework – это в основном инструментарий, потому что он состоит из FCL, который является библиотекой, и CLR, которая является виртуальной машиной. Таким образом, вы рассматриваете его как инструментарий для разработки C # в Windows. Mono является инструментарием для разработки C # в Linux. Но они назвали его основой. Это также имеет смысл думать об этом так же, поскольку это кадр вашего кода, но кадр должен больше поддерживать и удерживать вещи вместе, а затем выполнять любую работу, поэтому мое мнение заключается в том, что вы не должны использовать слово.

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

Думаю, это немного субъективно. Инструментарий самый простой. Это всего лишь куча методов, которые могут быть использованы.
Библиотека по сравнению с основным вопросом, который я использую, заключается в том, чтобы использовать их. Я где-то читал идеальный ответ давным-давно. Структура вызывает ваш код, но, с другой стороны, ваш код вызывает библиотеку.

Рамка: установлена ​​на вашем компьютере и позволяет вам взаимодействовать с ней. без frameworks вы не можете отправлять команды программирования на свой компьютер

Библиотека: предназначена для решения определенной проблемы (или нескольких проблем, связанных с одной и той же категорией)

Инструментарий: набор из множества fragmentов кода, который может решить множество проблем по нескольким проблемам (как и в случае с панелью инструментов)

В связи с правильным ответом Миттага:

простой пример. Предположим, вы реализуете интерфейс ISerializable (.Net) в одном из ваших classов. Вместо этого вы используете каркасные качества .Net, а не его библиотечные качества. Вы заполняете «белые пятна» (как сказал миттаг), и у вас есть скелет завершен. Вы должны заранее знать, как структура будет «реагировать» на ваш код. На самом деле .net – это основа, и здесь я не согласен с мнением Миттага.

Полный, полный ответ на ваш вопрос дается очень четко в главе 19 (вся глава, посвященная именно этой теме) этой книги , которая, кстати, очень хорошая книга (совсем не «только для Smalltalk»).

Другие отметили, что .net может быть как структурой, так и библиотекой и набором инструментов в зависимости от того, какую часть вы используете, но, возможно, пример помогает. Entity Framework для работы с базами данных является частью .net, которая использует инверсию шаблона управления. Вы даете ему знать свои модели, он выясняет, что с ними делать. Как программист, это требует от вас понимания «ума каркаса» или, что более реалистично, ум дизайнера и то, что они собираются делать с вашими входами. datareader и связанные с ним вызовы, с другой стороны, являются просто инструментом, позволяющим получить или поместить данные в таблицу и просмотреть ее и сделать ее доступной для вас. Он никогда не поймет, как взять родительские дочерние отношения и перевести его из объекта в реляционный, вы бы использовали несколько инструментов для этого. Но у вас будет гораздо больше контроля над тем, как эти данные были сохранены, когда, транзакции и т. Д.