Фреймворк против Инструментария против Библиотеки
В чем разница между платформой, инструментарием и библиотекой?
12 ответов
Наиболее важным отличием, а на самом деле определяющим отличием библиотеки от фреймворка является Inversion of Control.
Что это значит? Ну, это означает, что когда вы вызываете библиотеку, вы контролируете ситуацию. Но с фреймворком управление перевернуто: фреймворк зовет вас. (Это называется Голливудским принципом: не звоните нам, мы вам позвоним.) Это в значительной степени определение структуры. Если у него нет Inversion of Control, это не фреймворк. (Я смотрю на тебя.NET!)
По сути, весь поток управления уже находится в фреймворке, и есть только несколько предопределенных белых пятен, которые вы можете заполнить своим кодом.
Библиотека с другой стороны - это набор функций, которые вы можете вызвать.
Я не знаю, действительно ли термин инструментарий четко определен. Кажется, просто слово "набор" предполагает некоторую модульность, то есть набор независимых библиотек, которые вы можете выбирать. Что же делает инструментарий отличным от всего лишь нескольких независимых библиотек? Интеграция: если у вас просто есть несколько независимых библиотек, нет гарантии, что они будут хорошо работать вместе, в то время как библиотеки в наборе инструментов были разработаны для совместной работы - вам просто не нужно использовать все из них.
Но это действительно только моя интерпретация этого термина. В отличие от библиотеки и фреймворка, которые четко определены, я не думаю, что существует широко распространенное определение инструментария.
Мартин Фаулер обсуждает различие между библиотекой и фреймворком в своей статье об инверсии управления:
Инверсия управления - это ключевая часть того, что отличает фреймворк от библиотеки. Библиотека - это, по сути, набор функций, которые вы можете вызывать, в наши дни обычно организованные в классы. Каждый вызов выполняет некоторую работу и возвращает управление клиенту.
Фреймворк воплощает в себе некоторый абстрактный дизайн с большим количеством встроенного поведения. Чтобы использовать его, вам нужно вставить свое поведение в различные места фреймворка либо путем создания подклассов, либо путем подключения ваших собственных классов. Код платформы затем вызывает ваш код в этих точках.
Подводя итог: ваш код вызывает библиотеку, а фреймворк - ваш код.
схема
Если вы более визуальный ученик, вот диаграмма, которая проясняет это:
(Авторы: http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks)
Ответ, предложенный Мензани и Баррассом, является, вероятно, наиболее полным. Однако объяснение можно легко сформулировать более четко. Большинство людей упускают из виду тот факт, что это все вложенные понятия. Итак, позвольте мне выложить это для вас.
При написании кода:
- в конечном итоге вы обнаруживаете фрагменты кода, которые вы повторяете в своей программе, поэтому вы реорганизуете их в функции / методы.
- в конце концов, после написания нескольких программ, вы обнаруживаете, что копируете уже созданные вами функции в новые программы. Чтобы сэкономить время, вы объединяете эти функции в библиотеки.
- в конечном итоге вы обнаруживаете, что создаете один и тот же тип пользовательских интерфейсов каждый раз, когда используете определенные библиотеки. Таким образом, вы реорганизуете свою работу и создаете инструментарий, который позволяет вам легче создавать пользовательские интерфейсы из вызовов общих методов.
- в конце концов, вы написали так много приложений, которые используют те же наборы инструментов и библиотеки, что вы создали Framework, в котором уже имеется общая версия этого стандартного кода, поэтому все, что вам нужно сделать, - это создать внешний вид интерфейса и обрабатывать события, которые результат взаимодействия с пользователем.
Вообще говоря, это полностью объясняет различия между терминами.
Вступление
Существуют различные термины, относящиеся к коллекциям связанного кода, которые имеют как историческое значение (до 1994/5 для целей данного ответа), так и текущие значения, и читатель должен знать оба, особенно при чтении классических текстов по вычислительной технике / программированию. из исторической эпохи.
Библиотека
Исторически и в настоящее время библиотека представляет собой набор кода, относящегося к конкретной задаче, или набор тесно связанных задач, которые работают примерно на одном уровне абстракции. Как правило, в нем отсутствуют какие-либо собственные цели или намерения, и он предназначен для использования (потребления) и интеграции с клиентским кодом, чтобы помочь клиентскому коду в выполнении его задач.
Инструментарий
Исторически инструментарий - это более сфокусированная библиотека с определенной и конкретной целью. В настоящее время этот термин вышел из употребления и используется почти исключительно (насколько известно автору) для графических виджетов и компонентов графического интерфейса в текущую эпоху. Инструментарий чаще всего работает на более высоком уровне абстракции, чем библиотека, и часто сам использует и использует библиотеки. В отличие от библиотек, код инструментария часто используется для выполнения задачи клиентского кода, такой как построение окна, изменение размера окна и т. Д. Более низкие уровни абстракции в инструментарии либо фиксированы, либо могут управляться клиентом самостоятельно. код в запрещенной форме. (Подумайте о стиле Window s, который может быть исправлен или заранее изменен клиентским кодом.)
Фреймворк
Исторически фреймворк представлял собой набор взаимосвязанных библиотек и модулей, которые были разделены на категории "Общие" или "Особые". Общие платформы были призваны предложить всеобъемлющую и интегрированную платформу для создания приложений, предлагая общие функциональные возможности, такие как кроссплатформенное управление памятью, многопоточные абстракции, динамические структуры (и общие структуры в целом). Исторические общие рамки (без внедрения зависимостей, см. Ниже) почти повсеместно были заменены предложениями пакетного языка с полиморфными шаблонами (параметризованными) на языках OO, такими как STL для C++, или в пакетных библиотеках для не OO-языков (гарантированные заголовки Solaris C)). Общие фреймворки работали на разных уровнях абстракции, но повсеместно низком уровне, и подобно библиотекам полагались на клиентский код, выполняющий его конкретные задачи с их помощью.
"Особые" платформы исторически разрабатывались для одиночных (но часто растягивающихся) задач, таких как системы "Командование и управление" для промышленных систем и ранние стеки сетей, и работали на высоком уровне абстракции, и для выполнения выполнялись аналогичные наборы инструментов. клиентских кодов задач.
В настоящее время определение структуры стало более сфокусированным и основанным на принципе "инверсии контроля", который упоминается в другом месте в качестве руководящего принципа, поэтому выполнение программы, а также ее выполнение осуществляется структурой. Однако фреймворки все еще нацелены либо на конкретный результат; например, приложение для конкретной ОС (например, MFC для MS Windows) или для работы более общего назначения (например, среда Spring).
SDK: "Комплект разработки программного обеспечения"
SDK - это набор инструментов, помогающих программисту создавать и развертывать код / контент, который специально предназначен для работы на очень конкретной платформе или совершенно определенным образом. SDK может состоять из простого набора библиотек, которые должны использоваться особым образом только клиентским кодом и которые могут быть скомпилированы как обычно, вплоть до набора двоичных инструментов, которые создают или адаптируют двоичные ресурсы для его создания (SDK) выход.
двигатель
Движок (в терминах сбора кода) - это двоичный файл, который каким-то образом будет выполнять заказное содержимое или обрабатывать входные данные. Игровые и графические движки, пожалуй, являются наиболее распространенными пользователями этого термина и почти повсеместно используются с SDK для нацеливания на сам движок, такой как UDK (Unreal Development Kit), но существуют и другие движки, такие как поисковые движки и движки СУБД.,
Двигатель часто, но не всегда, позволяет только нескольким его внутренним элементам быть доступными для его клиентов. Чаще всего либо предназначаются для другой архитектуры, изменяют представление выходного сигнала двигателя, либо для целей настройки. Двигатели с открытым исходным кодом по определению открыты для клиентов, которые могут изменяться и изменяться по мере необходимости, а некоторые механизмы правильности исправлены полностью. Однако наиболее часто используемые движки в мире почти наверняка являются движками Javascript. Повсюду встроенный в каждый браузер, существует целый ряд движков JavaScript, которые будут принимать javascript в качестве входных данных, обрабатывать его, а затем выводить для рендеринга.
API: "Интерфейс прикладного программирования"
Последний термин, на который я отвечаю, - мой личный багбир: API, исторически использовался для описания внешнего интерфейса приложения или среды, которая сама по себе могла работать независимо или, по крайней мере, выполнять свои задачи без какого-либо вмешательства клиента после первоначального исполнения. Такие приложения, как базы данных, текстовые процессоры и системы Window s, будут предоставлять фиксированный набор внутренних хуков или объектов внешнему интерфейсу, которые клиент может затем вызывать / изменять / использовать и т. Д. Для реализации возможностей, которые может выполнять исходное приложение. API варьировался в зависимости от того, какая функциональность была доступна через API, а также от того, сколько базового приложения было (повторно) использовано клиентским кодом. (Например, API обработки текста может потребовать полной загрузки приложения в фоновом режиме при запуске каждого экземпляра клиентского кода или, возможно, только одной из его связанных библиотек; тогда как работающая система управления окнами создаст внутренние объекты, которые будут управляться самим собой, и передайте дескрипторы клиентскому коду, который будет использоваться вместо этого.
В настоящее время термин API имеет гораздо более широкий диапазон и часто используется для описания почти любого другого термина в этом ответе. Действительно, наиболее распространенное определение, применяемое к этому термину, заключается в том, что API предоставляет внешний интерфейс по контракту для другой части программного обеспечения (клиентский код для API). На практике это означает, что API зависит от языка и имеет конкретную реализацию, которая обеспечивается одной из вышеупомянутых коллекций кода, таких как библиотека, инструментарий или инфраструктура. Чтобы рассмотреть конкретную область, например, протоколы, API-интерфейс отличается от протокола, который является более общим термином, представляющим набор правил, однако это отдельная реализация определенного набора протоколов / протоколов, который предоставляет внешний интерфейс для другого программного обеспечения. чаще всего будет называться API.
замечание
Как отмечалось выше, исторические и текущие определения вышеприведенных терминов изменились, и это может быть связано с прогрессом в научном понимании основополагающих вычислительных принципов и парадигм, а также с появлением определенных моделей программного обеспечения. В частности, системы GUI и Windowing в начале девяностых помогли определить многие из этих терминов, но после эффективной гибридизации ядра ОС и системы Windowing для массовых операционных систем (за исключением, возможно, Linux) и массового внедрения внедрения зависимостей / инверсия контроля как механизма потребления библиотек и структур, эти термины должны были изменить свое значение.
PS (год спустя)
Тщательно продумав эту тему более года, я отвергаю принцип IoC как определяющее различие между фреймворком и библиотекой. Есть большое количество популярных авторов, которые говорят, что это так, но есть почти равное количество людей, которые говорят, что это не так. Просто существует слишком много "фреймворков", которые НЕ используют IoC, чтобы сказать, что это определяющий принцип. Поиск встроенных или микроконтроллерных фреймворков выявляет целое множество, которые НЕ используют IoC, и теперь я считаю, что язык.Net и CLR являются приемлемым потомком "общего" фреймворка. Я боюсь, что сказать, что IoC является определяющей характеристикой, просто слишком жестко, чтобы принять ее и отвергнуть все, что выдвигает себя в качестве основы, которая соответствует историческому представлению, как упомянуто выше.
Подробные сведения о инфраструктурах, отличных от IoC, см., Как упоминалось выше, во многих встроенных и микро-инфраструктурах, а также в любой исторической среде на языке, который не обеспечивает обратный вызов через язык (ОК. Обратные вызовы могут быть взломаны для любого устройства с современным зарегистрировать систему, но не среднестатистическим программистом) и, очевидно,.net framework.
Библиотека - это просто набор методов / функций, упакованных в пакет, которые можно импортировать в проект кода и использовать повторно.
Фреймворк - это надежная библиотека или набор библиотек, которые обеспечивают "основу" для вашего кода. Структура следует за шаблоном Инверсия Контроля. Например,.NET Framework - это большая коллекция связанных библиотек, в которых вы создаете свое приложение поверх. Вы можете утверждать, что между фреймворком и библиотекой нет большой разницы, но когда люди говорят "фреймворк", это обычно подразумевает больший, более надежный набор библиотек, которые будут играть неотъемлемую роль в приложении.
Я думаю о инструментарии так же, как и о SDK. Он поставляется с документацией, примерами, библиотеками, оболочками и т. Д. Опять же, вы можете сказать, что это то же самое, что и фреймворк, и вы, вероятно, были бы правы.
Почти все они могут быть использованы взаимозаменяемо.
Очень, очень похоже, среда обычно немного более развита и полна, чем библиотека, а инструментарий может просто представлять собой набор похожих библиотек и структур.
действительно хороший вопрос, который, возможно, даже немного субъективен по своей природе, но я считаю, что это лучший ответ, который я мог бы дать.
Библиотека
Я думаю, что единодушно, что библиотека уже закодирована, и вы можете использовать ее, чтобы вам не пришлось ее снова кодировать. Код должен быть организован таким образом, чтобы вы могли искать нужные вам функции и использовать их из своего собственного кода.
Большинство языков программирования поставляются со стандартными библиотеками, особенно с некоторым кодом, который реализует какую-то коллекцию. Это всегда для удобства, что вам не нужно кодировать эти вещи самостоятельно. Точно так же большинство языков программирования имеют конструкцию, позволяющую вам искать функциональность из библиотек, с такими вещами, как динамическое связывание, пространства имен и т. Д.
Таким образом, код, который часто требует повторного использования, - это отличный код, который можно поместить в библиотеку.
Инструментарий
Набор инструментов, используемых для определенной цели. Это единодушно. Вопрос в том, что считается инструментом, а что нет. Я бы сказал, что нет фиксированного определения, это зависит от контекста того, что называет себя инструментарием. Примером инструментов могут быть библиотеки, виджеты, скрипты, программы, редакторы, документация, серверы, отладчики и т. Д.
Еще одна вещь, которую стоит отметить, это "особая цель". Это всегда верно, но масштаб цели может легко измениться в зависимости от того, кто создал инструментарий. Таким образом, это может быть просто набор инструментов для программиста или набор инструментов для разбора строк. Один из них настолько широк, что может иметь инструмент, касающийся всего, что связано с программированием, а другой - более точный.
SDK - это, как правило, наборы инструментов, в которых они пытаются объединить набор инструментов (часто нескольких видов) в один пакет.
Я думаю, что общая нить заключается в том, что инструмент делает что-то для вас, либо полностью, либо помогает вам сделать это. А инструментарий - это просто набор инструментов, которые все выполняют или помогают вам выполнять определенный набор действий.
Фреймворк
Рамки не так однозначно определены. Похоже, это что-то вроде общего термина для всего, что может создать ваш код. Что означало бы: любую структуру, которая лежит в основе или поддерживает ваш код.
Это подразумевает, что вы строите свой код на основе фреймворка, тогда как вы создаете библиотеку на основе своего кода.
Но, похоже, иногда слово framework используется в том же смысле, что и инструментарий или даже библиотека..Net Framework - это в основном инструментарий, потому что он состоит из FCL, который является библиотекой, и CLR, который является виртуальной машиной. Так что вы бы посчитали это инструментарием для разработки C# под Windows. Mono - это инструментарий для разработки на C# в Linux. Все же они назвали это структурой. Имеет смысл думать об этом и таким образом, так как он создает рамки для вашего кода, но фрейм должен больше поддерживать и удерживать вещи вместе, чем выполнять какую-либо работу, поэтому я считаю, что это не тот способ, которым вы должны использовать слово.
И я думаю, что индустрия пытается перейти к созданию фреймворка, то есть уже написанной программы с недостающими частями, которые вы должны предоставить или настроить. Что, на мой взгляд, является хорошей вещью, так как инструментарий и библиотека являются отличными точными терминами для других употреблений "фреймворка".
Framework: устанавливается на вашем компьютере и позволяет вам взаимодействовать с ним. без фреймворка вы не можете отправлять команды программирования на ваш компьютер
Библиотека: стремится решить определенную проблему (или несколько проблем, относящихся к одной и той же категории)
Инструментарий: набор из множества кусков кода, который может решить несколько проблем по нескольким вопросам (как набор инструментов)
Это немного субъективно, я думаю. Инструментарий является самым простым. Это просто набор методов, классов, которые можно использовать.
Библиотека против фреймворка Вопрос, который я использую, имеет большое значение. Я где-то прочитал идеальный ответ давным-давно. Каркас вызывает ваш код, но, с другой стороны, ваш код вызывает библиотеку.
В связи с правильным ответом от Mittag:
простой пример. Допустим, вы реализуете ISerializable интерфейс (.Net) в одном из ваших классов. Тогда вы используете свойства среды.Net, а не ее библиотечные качества. Вы заполняете "белые пятна" (как сказал миттаг), и у вас есть скелет завершен. Вы должны заранее знать, как фреймворк будет "реагировать" на ваш код. На самом деле.net - это фреймворк, и здесь я не согласен с мнением Mittag.
Полный, полный ответ на ваш вопрос дается очень четко в главе 19 (целая глава, посвященная именно этой теме) этой книги, кстати, очень хорошая книга (совсем не "только для Smalltalk").
Другие отметили, что.net может быть как платформой, так и библиотекой и инструментарием, в зависимости от того, какую часть вы используете, но, возможно, пример поможет. Entity Framework для работы с базами данных является частью.net, которая использует инверсию шаблона управления. Вы даете ему знать ваши модели, он выясняет, что с ними делать. Как программисту требуется, чтобы вы понимали "разум фреймворка" или, более реалистично, ум дизайнера и то, что они собираются делать с вашими входами. С другой стороны, datareader и связанные вызовы - это просто инструмент, позволяющий получить или поместить данные в таблицу / представление и из нее и сделать их доступными для вас. Он никогда не поймет, как взять родительские дочерние отношения и перевести их из объекта в реляционный, для этого нужно использовать несколько инструментов. Но у вас будет гораздо больше контроля над тем, как эти данные хранятся, когда, транзакции и т. Д.