Il concetto di libreria software è analogo a quello di libreria fisica: entrambi sono oggetti da cui è possibile attingere e riutilizzare conoscenza pregressa.
Il termine libreria nasce da una fallace trasposizione lessicale dell'inglese library (letteralmente, biblioteca), ma ormai è così diffuso nel vocabolario dei professionisti da essere accettato quale possibile traduzione.
Scopo ed utilizzo
Lo scopo delle librerie software è fornire una collezione di entità di base pronte per l'uso ovvero riuso di codice, evitando al programmatore di dover riscrivere ogni volta le stesse funzioni o strutture dati e facilitando così le operazioni di sviluppo e manutenzione. Questa caratteristica si inserisce quindi nel più vasto contesto del 'richiamo di codice' all'interno di programmi e applicazioni ed è presente in quasi tutti i linguaggi. I vantaggi principali derivanti dall'uso di un simile approccio sono i seguenti:
Si può separare la logica di programmazione di una certa applicazione da quella necessaria per la risoluzione di problemi specifici, quali il calcolo di funzioni matematiche o la gestione delle collezioni;
Le entità definite in una certa libreria possono essere riutilizzate da più applicazioni;
Si può modificare la libreria separatamente dal programma, senza limiti alla potenziale vastità di funzioni e strutture dati man mano disponibili nel tempo.
Tipologie
Quasi tutti i linguaggi di programmazione supportano il concetto di libreria e moltissimi includono delle librerie standardizzate (spesso chiamate proprio librerie standard del linguaggio in questione): si tratta di un insieme di funzioni e/o strutture dati che permettono di risolvere i problemi di programmazione più comuni. Ad esempio, molti linguaggi di programmazione hanno una libreria matematica, che consente di eseguire elevamenti a potenza, il calcolo dei logaritmi e così via; funzioni di I/O; funzioni e strutture dati per la gestione di collezioni di oggetti e altre. Java e Dotnet dispongono di una moltitudine di librerie (package) per le più svariate funzioni, importabili e attivabili nell'ambiente di sviluppo.
Le librerie standard, rispetto a quelle non-standard, consentono una più agevole portabilità degli applicativi che le sfruttano; infatti, ogni produttore di compilatori è tenuto a includere una certa implementazione delle librerie standard; questo significa che le librerie sono potenzialmente supportate da tutte le piattaforme per le quali esiste un compilatore specifico. Viceversa, una libreria non-standard potrebbe non essere supportata su un certo sistema.
Librerie statiche
Quando il collegamento viene eseguito durante la creazione di un eseguibile o di un altro file oggetto, è noto come collegamento statico o collegamento anticipato. In questo caso, il collegamento viene solitamente eseguito da un linker, ma può anche essere eseguito dal compilatore. Una libreria statica, nota anche come archivio, è pensata per essere collegata staticamente. In origine esistevano solo librerie statiche. Il collegamento statico deve essere eseguito quando vengono ricompilati i moduli.
Tutti i moduli richiesti da un programma a volte sono collegati staticamente e copiati nel file eseguibile. Questo processo e il file autonomo risultante è noto come costruzione statica del programma. Una costruzione statica potrebbe non richiedere ulteriori riposizionamenti se viene utilizzata la memoria virtuale e non si desidera la casualizzazione dello spazio degli indirizzi[1].
Una libreria condivisa è un archivio di codice eseguibile che può essere caricato da più processi contemporaneamente.
Questo genere di librerie viene collegato ai programmi in fase di esecuzione tramite funzioni dedicate del sistema operativo, in particolare il dynamic linker.
L'algoritmo di collegamento in fase di esecuzione è alquanto sofisticato e permette, tra le altre cose, di sostituire al volo il codice della libreria senza modificare l'applicazione che lo richiede. Per questo motivo si parla di collegamento dinamico e per estensione di librerie dinamiche.
La separazione del codice in librerie a collegamento dinamico permette di suddividere il codice eseguibile in parti concettualmente separate, che verranno caricate solo se effettivamente necessarie. Inoltre, una singola libreria, caricata in memoria, può essere utilizzata da più programmi, senza la necessità di essere nuovamente caricata, il che permette di risparmiare le risorse del sistema. Questo metodo di loading on demand consente, inoltre, installazioni parziali di un sistema software, in cui sono effettivamente presenti sulla memoria di massa solo le librerie associate alle funzioni che l'utente desidera utilizzare, come selezionate in fase di installazione.
Un altro vantaggio è la possibilità di aggiornare un programma modificando solo le librerie: inserendo una versione diversa della libreria, che contiene ad esempio dei bug fix, tutti i programmi che la usano saranno automaticamente "aggiornati" senza bisogno di essere ricompilati.
Il principale svantaggio è legato al fatto che una nuova versione di una libreria potrebbe effettuare dei cosiddetti breaking changes, in modo volontario o, inconsapevolmente, a causa di bug nella nuova versione. Un breaking change è un cambiamento critico nel comportamento del codice della funzione che la rende non più compatibile con le convenzioni in uso (ad esempio, una funzione che prima restituiva NULL in caso di errore nei parametri e che ora setta errno e restituisce un valore non nullo). Ancora più critico il caso in cui un programma di installazione sovrascriva una DLL con una versione più vecchia. Altri problemi possono verificarsi in ambiente COM. Questi problemi, ben noti ai programmatori Windows, sono raggruppati sotto il nome di DLL hell (inferno delle DLL).
In alcuni sistemi operativi, tipicamente Unix e Unix-like, è possibile far convivere versioni diverse, fra loro incompatibili, di una stessa libreria, purché siano singolarmente presenti sul file system in differenti percorsi e sia possibile, in fase di collegamento del programma, l'identificazione della versione corretta di libreria da utilizzare. In questa maniera, i programmi collegati prima dell'installazione della nuova libreria possono continuare ad avvalersi della vecchia versione.[2]
Librerie di oggetti e classi
La maggior parte dei fornitori di minicomputer e mainframe ha avviato progetti per combinare i due, producendo un formato di libreria OOP che potrebbe essere utilizzato ovunque. Tali sistemi erano noti come librerie di oggetti o oggetti distribuiti, se supportavano l'accesso remoto (non tutti lo facevano). COM di Microsoft è un esempio di un tale sistema per uso locale. DCOM, una versione modificata di COM, supporta l'accesso remoto.
Le librerie di classi sono l'equivalente approssimativo OOP dei vecchi tipi di librerie di codice. Contengono classi, che descrivono le caratteristiche e definiscono azioni (metodi) che coinvolgono oggetti. Le librerie di classi vengono utilizzate per creare istanze o oggetti con le loro caratteristiche impostate su valori specifici. In alcuni linguaggi OOP, come Java, la distinzione è chiara, con le classi spesso contenute nei file di libreria (come il formato di file JAR di Java) e gli oggetti istanziati che risiedono solo nella memoria (sebbene potenzialmente in grado di essere resi persistenti in file separati). In altri, come Smalltalk, le librerie di classi sono semplicemente il punto di partenza per un'immagine di sistema che include l'intero stato dell'ambiente, le classi e tutti gli oggetti istanziati.
Librerie remote
Un'altra soluzione al problema della libreria deriva dall'utilizzo di eseguibili completamente separati (spesso in una forma leggera) e dal chiamarli utilizzando una chiamata di procedura remota (RPC) su una rete a un altro computer.
Librerie di generazione del codice
Le librerie di generazione del codice sono API di alto livello in grado di generare o trasformare il codice byte per Java. Sono usati dalla programmazione orientata agli aspetti, alcuni framework di accesso ai dati e per i test per generare oggetti proxy dinamici. Sono anche usati per intercettare l'accesso al campo[3].
Il sistema archivia libfoo.ae file libfoo.so in directory come /lib, /usr/libo /usr/local/lib. I nomi dei file iniziano sempre con libe finiscono con un suffisso di .a(archivio, libreria statica) o di .so(oggetto condiviso, libreria collegata dinamicamente). Alcuni sistemi potrebbero avere più nomi per la libreria collegata dinamicamente, con la maggior parte dei nomi per collegamenti simbolici al nome rimanente; quei nomi potrebbero includere la versione principale della libreria o il numero di versione completo; ad esempio, su alcuni sistemi libfoo.so.2sarebbe il nome del file per la seconda revisione principale dell'interfaccia della libreria collegata dinamicamente libfoo. I file.la che a volte si trovano nelle directory della libreria sono archivi libtool, non utilizzabili dal sistema in quanto tale.
Il sistema eredita le convenzioni della libreria statica da BSD, con la libreria memorizzata in un file .a, e può utilizzare librerie .so collegate dinamicamente in stile (con invece il suffisso .dylib). La maggior parte delle librerie in macOS, tuttavia, sono costituite da "framework", collocati all'interno di directory speciali chiamate "bundle" che racchiudono i file e i metadati richiesti dalla libreria. Ad esempio, un framework chiamato MyFrameworkverrebbe implementato in un bundle chiamato MyFramework.framework, MyFramework.framework/MyFrameworkessendo il file di libreria collegato dinamicamente o un collegamento simbolico al file di libreria collegato dinamicamente in MyFramework.framework/Versions/Current/MyFramework.
Le librerie a collegamento dinamico di solito hanno il suffisso *.DLL,[4] sebbene altre estensioni di nomi di file possano identificare librerie collegate dinamicamente per scopi specifici, ad esempio *.OCXper le librerie OLE. Le revisioni dell'interfaccia sono codificate nei nomi dei file o astratte utilizzando le interfacce degli oggetti COM. A seconda di come vengono compilati, i file*.LIB possono essere librerie statiche o rappresentazioni di librerie collegabili dinamicamente necessarie solo durante la compilazione, note come " librerie di importazione ". A differenza del mondo UNIX, che utilizza estensioni di file diverse, quando si collega al file .LIB in Windows bisogna prima sapere se si tratta di una normale libreria statica o di una libreria di importazione. In quest'ultimo caso, un file .DLL deve essere presente in fase di esecuzione.
«Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.»
