Librerie vs. Frameworks – Qual è la differenza?

La pagina di Wikipedia per una libreria di codice la definisce come:

“In informatica, una libreria è una collezione di risorse non volatili usate dai programmi per computer, spesso per lo sviluppo del software. Queste possono includere dati di configurazione, documentazione, dati di aiuto, modelli di messaggi, codice pre-scritto e subroutine, classi, valori o specifiche di tipo.”

Confronto con la definizione di un framework:

“Nella programmazione informatica, un framework software è un’astrazione in cui il software che fornisce funzionalità generiche può essere selettivamente modificato da ulteriore codice scritto dall’utente, fornendo così software specifico dell’applicazione.

Fornisce un modo standard per costruire e distribuire applicazioni ed è un ambiente software universale e riutilizzabile che fornisce particolari funzionalità come parte di una più ampia piattaforma software per facilitare lo sviluppo di applicazioni, prodotti e soluzioni software.”

C’è molto da spacchettare, ma se avete lavorato con entrambi, probabilmente potete già vedere che, generalmente, una libreria di codice viene utilizzata per risolvere un problema specifico o aggiungere una caratteristica specifica al vostro programma.

Un framework, d’altra parte, vi fornisce qualcosa di molto più generico e riutilizzabile. Se continuate a leggere la voce di Wikipedia, noterete che tre cose separano un framework da una libreria.

Inversione di controllo

Le librerie si collegano al vostro codice, il vostro codice si collega a un framework.

La prima grande differenza tra un framework e una libreria è chi ha il controllo del processo di sviluppo. Un framework generalmente richiede che lo sviluppatore sia completamente immerso nel suo flusso di lavoro.

Di conseguenza, spesso sembra che sia il framework a controllare il processo di sviluppo piuttosto che lo sviluppatore. Questa è inversione di controllo! Questo è comunemente semplificato come una qualche variazione di quanto segue:

  • Libreria: Chiamateci per portare a termine il lavoro.
  • Framework: Tu non ci chiami, noi chiamiamo te.

È a causa di questa inversione di controllo che i framework sono molto più opinionati e anche perché sono in grado di fare così tanto per gli sviluppatori.

Opinionate per chi se lo chiede significa che i framework stanno prendendo molte decisioni riguardo a come il codice è scritto, la posizione dei file e forse anche il nome di detti file.

Making these assumptions allows for the usage of the paradigm of convention over configuration which allows developers to skip the process of app configuration in exchange for following certain conventions (such as putting certain files in certain folders, etc.).

Ruby on Rails is a popular framework for developing web applications.

Look at a framework like Ruby on Rails. It is often considered highly opinionated. Quando si crea un nuovo progetto con Ruby on Rails, esso genererà numerose cartelle e file con un sacco di codice pre-scritto.

La maggior parte del lavoro dello sviluppatore sarà probabilmente fatto nella cartella app (questa è la posizione dei modelli, delle viste, delle sotto-cartelle dei controllori) ma c’è un sacco di altro codice in quel progetto Rails che è progettato per far funzionare la vostra applicazione.

Inoltre, Ruby on Rails ha un flusso di lavoro specifico che si aspetta che seguiate. Quando create un modello User in Rails, presume che sia legato ad un UsersController.

Rails vuole che quei file siano nominati in un certo modo (user.rb per il modello e users_controller.rb per il controller) e li vuole nelle loro rispettive cartelle. Work with it and everything just seems to magically work.

A large part of that magic (some do refer to it as Rails magic) is just all of that pre-written code working in the background. You fill in the models, views, controllers, and draw some routes, and Rails will take care of linking everything up correctly.

ChartJS lets you make some really beautiful charts.

Compare this to Chart.js which is a JavaScript library for creating really beautiful charts.

Si sceglie quando e dove chiamare Chart.js e mentre è vero che viene richiesto di riempire dei campi quando si crea un nuovo grafico (si vuole specificare il tipo di grafico, le etichette, i colori, ecc.) non controlla il vostro flusso di lavoro.

Chart.js si preoccupa solo delle informazioni necessarie per disegnare un grafico; non potrebbe importargli di meno del resto del vostro codice.

Extensibilità

Un concetto importante nella programmazione orientata agli oggetti è il principio aperto-chiuso. Il principio aperto-chiuso afferma che il comportamento del codice dovrebbe essere aperto ad essere alterato/esteso senza dover essere cambiato direttamente.

Un semplice esempio di questo è l’ereditarietà nelle classi che permette ad una sottoclasse di aggiungere funzionalità e caratteristiche necessarie ad essa senza mai aver bisogno di cambiare direttamente il codice nella classe madre.

L’estensibilità permette ad uno sviluppatore di aggiungere nuove caratteristiche ad un framework o adattare il comportamento delle caratteristiche esistenti per soddisfare i propri bisogni senza modificare il codice sorgente.

I buoni framework sono costruiti con l’estensibilità in mente. Forniscono le funzionalità generiche necessarie per sviluppare un’applicazione generica, ma si lasciano aperti ad aggiunte e modifiche specifiche necessarie per un’applicazione specifica.

Se un framework non fosse estensibile, sarebbe piuttosto limitato nelle sue funzionalità e questo lo renderebbe molto meno attraente da imparare.

Seguendo gli esempi di cui sopra, ci sono diverse estensioni per il framework Ruby on Rails per aggiungere funzionalità aggiuntive come l’autenticazione dell’utente.

Se Rails non avesse queste estensioni, ostacolerebbe gravemente ciò che si potrebbe fare usando il framework. Ad essere onesti, anche Chart.js ha molti plugin ed estensioni. Queste permettono cose come disegnare ulteriori tipi di grafici.

La differenza qui è molto meno visibile, comunque, perché i framework forniscono funzionalità generali, dovrebbero essere costruiti con l’estensibilità in mente in modo che le caratteristiche specifiche dell’applicazione possano essere implementate.

Una libreria non ha necessariamente bisogno di essere costruita con l’estensibilità in mente, il suo scopo primario è quello di realizzare un compito specifico.

Codice non modificabile

Questo concetto è fortunatamente molto più facile e semplice da spiegare. La risposta breve e semplice è che i framework generano un mucchio di codice e per la maggior parte, non si tocca quel codice.

Tornando a Rails come spiegato prima, generalmente, uno sviluppatore spende la maggior parte del suo tempo lavorando sulla cartella dell’app. Lo sviluppatore generalmente non cambierà o cancellerà il codice pre-scritto.

Lascia un commento