Библиотеки в программировании: концепция и виды.

Введение

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

Концепция в разработке программного обеспечения.

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

Общий

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

Исполняемое

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

История

Идея компьютерной библиотеки восходит к первым компьютерам, созданным Чарльзом Бэббиджем. В 1888 году в статье о его аналитической машине было предложено, что компьютерные операции можно было бы записывать на отдельные карты, отличные от цифровых входных данных. Если бы эти операционные перфокарты сохранялись для повторного использования, то «машина постепенно обзавелась бы собственной библиотекой». В 1947 году Голдстайн и фон Нейман предположили, что было бы полезно создать «библиотеку» подпрограмм для их работы над машиной IAS — ранним компьютером, который в то время еще не был введен в эксплуатацию. Они представляли себе физическую библиотеку магнитных записей, где каждая лента хранила бы многократно используемый компьютерный код. Вдохновленный фон Нейманом, Уилкс и его команда построили EDSAC. Библиотека подпрограмм для этого компьютера хранилась в картотеке с перфолентами. Программы для EDSAC состояли из основной программы и последовательности подпрограмм, скопированных из библиотеки подпрограмм. В 1951 году команда опубликовала первый учебник по программированию «Подготовка программ для электронной цифровой вычислительной машины», в котором подробно описывалось создание и назначение библиотеки. В 1959 году COBOL включал «элементарные средства для библиотечной системы», но Жан Саммет впоследствии описала их как «недостаточные библиотечные возможности». JOVIAL имеет Communication Pool (COMPOOL) — своего рода библиотеку файлов заголовков. Еще один важный вклад в современную концепцию библиотеки внесла инновация подпрограмм в FORTRAN. Подпрограммы FORTRAN можно компилировать независимо друг от друга, но компилятору не хватало компоновщика. Поэтому до появления модулей в Fortran 90 проверка типов между подпрограммами FORTRAN была невозможна. К середине 1960-х годов библиотеки копий и макросов для ассемблеров стали обычным явлением. С момента появления популярности IBM System/360 библиотеки, содержащие другие типы текстовых элементов, например, системные параметры, также стали распространены. В ОС/360 IBM и ее последующих версиях это называется разделяемым набором данных. Первый объектно-ориентированный язык программирования Simula, разработанный в 1965 году, поддерживал добавление классов в библиотеки через компилятор.

The idea of a computer library dates back to the first computers created by Charles Babbage. An 1888 paper on his Analytical Engine suggested that computer operations could be punched on separate cards from numerical input. If these operation punch cards were saved for reuse then "by degrees the engine would have a library of its own." In 1947 Goldstine and von Neumann speculated that it would be useful to create a "library" of subroutines for their work on the IAS machine, an early computer that was not yet operational at that time. They envisioned a physical library of magnetic wire recordings, with each wire storing reusable computer code. Inspired by von Neumann, Wilkes and his team constructed EDSAC. A filing cabinet of punched tape held the subroutine library for this computer. Programs for EDSAC consisted of a main program and a sequence of subroutines copied from the subroutine library. In 1951 the team published the first textbook on programming, The Preparation of Programs for an Electronic Digital Computer, which detailed the creation and the purpose of the library. COBOL included "primitive capabilities for a library system" in 1959, but Jean Sammet described them as "inadequate library facilities" in retrospect. JOVIAL has a Communication Pool (COMPOOL), roughly a library of header files. Another major contributor to the modern library concept came in the form of the subprogram innovation of FORTRAN. FORTRAN subprograms can be compiled independently of each other, but the compiler lacked a linker. So prior to the introduction of modules in Fortran 90, type checking between FORTRAN subprograms was impossible. By the mid 1960s, copy and macro libraries for assemblers were common. Starting with the popularity of the IBM System/360, libraries containing other types of text elements, e. g., system parameters, also became common. In IBM's OS/360 and its successors this is called a partitioned data set. The first object oriented programming language, Simula, developed in 1965, supported adding classes to libraries via its compiler.

Связывание

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

Перемещение

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

Статические библиотеки

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

Общие библиотеки

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

Библиотеки объектов

Хотя динамическая связь была впервые разработана в 1960-х годах, она не получила широкого распространения в наиболее используемых операционных системах до конца 1980-х годов. К началу 1990-х годов она была доступна в той или иной форме в большинстве операционных систем. В этот же период объектно-ориентированное программирование (ООП) становилось важной частью программной среды. ООП с динамической привязкой требует дополнительной информации, которую традиционные библиотеки не предоставляют. Помимо имен и точек входа кода, содержащегося в них, они также требуют список объектов, от которых они зависят. Это является побочным эффектом одной из ключевых концепций ООП – наследования, означающей, что части полного определения любого метода могут располагаться в разных местах. Это не просто указание на то, что одна библиотека использует сервисы другой: в настоящей ООП-системе сами библиотеки могут быть неизвестны на этапе компиляции и различаться в зависимости от системы. Одновременно многие разработчики работали над идеей многоуровневых программ, в которых "дисплей", работающий на настольном компьютере, использовал бы ресурсы мейнфрейма или миникомпьютера для хранения или обработки данных. Например, программа с графическим интерфейсом отправляла бы сообщения на миникомпьютер для получения небольших выборок из огромного набора данных для отображения. Удаленные вызовы процедур (RPC) уже решали эти задачи, но не существовало стандартной RPC-системы. Вскоре большинство производителей миникомпьютеров и мейнфреймов начали проекты по объединению этих двух подходов, создав формат объектной библиотеки ООП, который можно было бы использовать повсеместно. Такие системы назывались объектными библиотеками или распределенными объектами, если они поддерживали удаленный доступ (не все поддерживали). Microsoft COM является примером такой системы для локального использования. DCOM, модифицированная версия COM, поддерживает удаленный доступ. В течение некоторого времени объектные библиотеки считались "следующим большим прорывом" в мире программирования. Было предпринято множество попыток создать кроссплатформенные системы, и компании конкурировали, чтобы привлечь разработчиков к своим решениям. Примеры включают IBM System Object Model (SOM/DSOM), Sun Microsystems' Distributed Objects Everywhere (DOE), NeXT's Portable Distributed Objects (PDO), Digital's ObjectBroker, Microsoft's Component Object Model (COM/DCOM) и множество систем на основе CORBA.

Although originally pioneered in the 1960s, dynamic linking did not reach the most commonly used operating systems until the late 1980s. It was generally available in some form in most operating systems by the early 1990s. During this same period, object oriented programming (OOP) was becoming a significant part of the programming landscape. OOP with runtime binding requires additional information that traditional libraries do not supply. In addition to the names and entry points of the code located within, they also require a list of the objects they depend on. This is a side effect of one of OOP's core concepts, inheritance, which means that parts of the complete definition of any method may be in different places. This is more than simply listing that one library requires the services of another: in a true OOP system, the libraries themselves may not be known at compile time, and vary from system to system. At the same time many developers worked on the idea of multi tier programs, in which a "display" running on a desktop computer would use the services of a mainframe or minicomputer for data storage or processing. For instance, a program on a GUI based computer would send messages to a minicomputer to return small samples of a huge dataset for display. Remote procedure calls (RPC) already handled these tasks, but there was no standard RPC system. Soon the majority of the minicomputer and mainframe vendors instigated projects to combine the two, producing an OOP library format that could be used anywhere. Such systems were known as object libraries, or distributed objects, if they supported remote access (not all did). Microsoft's COM is an example of such a system for local use. DCOM, a modified version of COM, supports remote access. For some time object libraries held the status of the "next big thing" in the programming world. There were a number of efforts to create systems that would run across platforms, and companies competed to try to get developers locked into their own system. Examples include IBM's System Object Model (SOM/DSOM), Sun Microsystems' Distributed Objects Everywhere (DOE), NeXT's Portable Distributed Objects (PDO), Digital's ObjectBroker, Microsoft's Component Object Model (COM/DCOM), and any number of CORBA based systems.

Классические библиотеки

Библиотеки классов — это приблизительный объектно-ориентированный эквивалент более старых типов библиотек кода. Они содержат классы, которые описывают характеристики и определяют действия (методы), связанные с объектами. Библиотеки классов используются для создания экземпляров, то есть объектов с заданными значениями их характеристик. В некоторых объектно-ориентированных языках, таких как Java, различие чёткое: классы часто хранятся в библиотечных файлах (например, в формате JAR для Java), а созданные объекты существуют только в памяти (хотя их можно сохранить в отдельных файлах). В других языках, например, Smalltalk, библиотеки классов служат лишь отправной точкой для системного образа, включающего в себя всё состояние среды, включая классы и все созданные объекты. Сегодня большинство библиотек классов хранятся в репозиториях пакетов (например, Maven Central для Java). Клиентский код явно указывает зависимости от внешних библиотек в файлах конфигурации сборки (например, в файле Maven Pom для Java).

Удаленные библиотеки

Другой подход к организации библиотек использует полностью отдельные исполняемые файлы (часто в облегчённой форме) и вызывает их посредством удалённого вызова процедур (RPC) по сети на другом компьютере. Это обеспечивает максимальное повторное использование операционной системы: код, необходимый для поддержки библиотеки, тот же, что и для обеспечения поддержки приложений и безопасности для всех остальных программ. Кроме того, в таких системах библиотека не обязательно должна находиться на той же машине, запросы могут перенаправляться по сети. Однако такой подход означает, что каждое обращение к библиотеке сопряжено со значительными накладными расходами. RPC-вызовы гораздо дороже, чем вызов общей библиотеки, которая уже загружена в память на той же машине. Этот подход часто применяется в распределённых архитектурах, активно использующих удалённые вызовы, например, в клиент-серверных системах и серверах приложений, таких как Enterprise JavaBeans.

Библиотеки генерации кода

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

Большинство современных Unix-подобных систем

Система хранит файлы libfoo.a и libfoo.so в каталогах, таких как /lib, /usr/lib или /usr/local/lib. Имена файлов всегда начинаются с lib и заканчиваются суффиксом a (архив, статическая библиотека) или so (динамически подключаемая библиотека, общий объект). Некоторые системы могут использовать несколько имен для динамически подключаемой библиотеки. Эти имена обычно имеют общий префикс и различные суффиксы, указывающие номер версии. Большинство из этих имен являются именами символических ссылок на последнюю версию. Например, на некоторых системах libfoo.so.2 будет именем файла для второй основной ревизии интерфейса динамически подключаемой библиотеки libfoo. Файлы la, которые иногда встречаются в каталогах библиотек, представляют собой архивы libtool и не могут быть использованы системой напрямую.

macOS

Система наследует соглашения о статических библиотеках от BSD, где библиотека хранится в файле с расширением .a, и может использовать динамически связанные библиотеки (с суффиксом dylib). Однако большинство библиотек в macOS состоят из "фреймворков", размещенных в специальных каталогах, называемых "пакетами" (bundles), которые содержат необходимые файлы и метаданные библиотеки. Например, фреймворк с именем MyFramework реализуется в пакете с именем MyFramework.framework, где MyFramework.framework/MyFramework является либо файлом динамически связанной библиотеки, либо символической ссылкой на файл динамически связанной библиотеки, расположенный в MyFramework.framework/Versions/Current/MyFramework.

Microsoft Windows

Динамически подключаемые библиотеки обычно имеют суффикс *.DLL, хотя другие расширения имен файлов могут указывать на динамически связанные библиотеки специального назначения, например, *.OCX для библиотек OLE. Версии интерфейсов либо кодируются в именах файлов, либо скрыты с помощью COM-интерфейсов объектов. В зависимости от способа компиляции, файлы *.LIB могут быть как статическими библиотеками, так и представлениями динамически подключаемых библиотек, необходимых только на этапе компиляции, известные как "библиотеки импорта". В отличие от мира UNIX, использующего различные расширения файлов, при подключении к файлу LIB в Windows необходимо сначала определить, является ли это обычной статической библиотекой или библиотекой импорта. В последнем случае файл DLL должен присутствовать во время выполнения программы.