Ответ 1

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

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

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

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

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

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

Ответ 2

Мартин Фаулер обсуждает разницу между библиотекой и каркасом в своей статье о Inversion of Control:

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

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

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

Ответ 3

Введение

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

Библиотека

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

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

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

Framework

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

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

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

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) и массовое внедрение инъекции/инверсия управления как механизма потребления библиотек и фреймворков, эти термины должны были изменить их соответствующие значения.

P.S. (Год спустя)

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

Библиотека

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

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

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

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

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

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

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

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

Framework

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

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