Bibliotheken vs. Frameworks – Wat is het verschil?

De Wikipedia-pagina voor een codebibliotheek definieert deze als:

“In de informatica is een bibliotheek een verzameling niet-vluchtige bronnen die door computerprogramma’s worden gebruikt, vaak voor de ontwikkeling van software. Dit kunnen configuratiegegevens, documentatie, helpgegevens, berichtsjablonen, vooraf geschreven code en subroutines, klassen, waarden of typespecificaties zijn.”

Vergeleken we dat met de definitie van een framework:

“In computerprogrammering is een softwareframework een abstractie waarin software die generieke functionaliteit biedt, selectief kan worden gewijzigd door extra door de gebruiker geschreven code, waardoor toepassingsspecifieke software wordt geboden.

Het biedt een standaardmanier om toepassingen te bouwen en in te zetten en is een universele, herbruikbare softwareomgeving die bepaalde functionaliteit biedt als onderdeel van een groter softwareplatform om de ontwikkeling van softwaretoepassingen, -producten en -oplossingen te vergemakkelijken.”

Er is daar veel uit te pakken, maar als je met beide hebt gewerkt, kun je waarschijnlijk al zien dat, over het algemeen, een code library wordt gebruikt om een specifiek probleem op te lossen of een specifieke functie aan je programma toe te voegen.

Een framework, aan de andere kant, biedt je iets veel algemeners en herbruikbaars. Als je de Wikipedia-tekst blijft lezen, zul je zien dat er drie dingen zijn die een framework onderscheiden van een library.

Inversie van controle

Libraries plug in your code, Your code plug in a framework.

Het eerste grote verschil tussen een framework en een bibliotheek is wie de controle heeft over het ontwikkelproces.

Bij een codebibliotheek doet een ontwikkelaar doorgaans een beroep op de bibliotheek wanneer hij dat nodig acht. Een framework vereist over het algemeen dat de ontwikkelaar volledig wordt ondergedompeld in zijn workflow.

Als gevolg daarvan voelt het vaak alsof het framework de controle heeft over het ontwikkelproces in plaats van de ontwikkelaar. Dit is omkering van controle! Dit wordt meestal gesimplificeerd als een variatie van het volgende:

  • Library: Bel ons om de klus te klaren.
  • Framework: U belt ons niet, wij bellen u.

Het is vanwege deze omkering van controle dat frameworks veel meer opiniërend zijn en ook waarom ze in staat zijn om zoveel voor ontwikkelaars te doen.

Opinionated voor degenen die zich afvragen betekent dat frameworks veel beslissingen nemen over hoe code wordt geschreven, de locatie van bestanden, en mogelijk zelfs de naam van die bestanden.

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. Als je met Ruby on Rails een nieuw project maakt, genereert het talloze mappen en bestanden met veel vooraf geschreven code.

Het meeste werk van de ontwikkelaar zal waarschijnlijk worden gedaan in de app-map (dit is de locatie van de submappen van de modellen, views en controllers), maar er is genoeg andere code in dat Rails-project die is ontworpen om je applicatie aan de praat te krijgen.

Meer nog, Ruby on Rails heeft een specifieke workflow waarvan het verwacht dat je die volgt. Wanneer je een User model in Rails maakt, gaat het ervan uit dat het gekoppeld is aan een UsersController.

Rails wil die bestanden op een bepaalde manier benoemen (user.rb voor het model en users_controller.rb voor de controller) en wil ze in hun respectievelijke mappen.

Afwijken van Rails’ workflow zal je gefrustreerd achterlaten over hoe en waarom je code niet werkt. 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.

Je kiest zelf wanneer en waar je Chart.js aanroept en hoewel het waar is dat je velden moet invullen wanneer je een nieuwe grafiek maakt (je zult het type grafiek willen specificeren, labels, kleuren, etc.) controleert het je workflow niet.

Chart.js geeft alleen om de informatie die nodig is om een grafiek te tekenen; de rest van je code kan het niets schelen.

Extensibility

Een belangrijk concept in object-georiënteerd programmeren is het open-gesloten principe. Het open-closed principe stelt dat het gedrag van code moet kunnen worden veranderd/uitgebreid zonder dat het direct hoeft te worden veranderd.

Een eenvoudig voorbeeld hiervan is overerving in klassen, die een subklasse in staat stelt functionaliteit en mogelijkheden toe te voegen zonder ooit direct code in de bovenliggende klasse te hoeven veranderen.

Extensibility stelt een ontwikkelaar in staat nieuwe mogelijkheden aan een framework toe te voegen of het gedrag van bestaande mogelijkheden aan te passen aan hun behoeften zonder de broncode aan te passen.

Goede frameworks zijn gebouwd met uitbreidbaarheid in gedachten. Ze bieden de generieke functionaliteit die nodig is om een generieke applicatie te ontwikkelen, maar laten zichzelf open voor specifieke toevoegingen en wijzigingen die nodig zijn voor een specifieke toepassing.

Als een framework niet uitbreidbaar zou zijn, zou het nogal beperkt zijn in zijn functionaliteit en dit zou het veel minder aantrekkelijk maken om te leren.

Om bij de voorbeelden hierboven te blijven, zijn er verschillende extensies voor het Ruby on Rails framework om extra functies toe te voegen, zoals authenticatie van gebruikers.

Als Rails deze extensies niet zou hebben, zou dat een ernstige belemmering zijn voor wat je ermee zou kunnen maken. Om eerlijk te zijn, Chart.js heeft ook veel plugins en extensies. Deze maken dingen mogelijk als het tekenen van extra soorten grafieken.

Het verschil hier is echter veel minder zichtbaar, omdat frameworks algemene functionaliteit bieden, moeten ze worden gebouwd met uitbreidbaarheid in het achterhoofd, zodat app-specifieke functies kunnen worden geïmplementeerd.

Een library hoeft niet noodzakelijkerwijs te worden gebouwd met uitbreidbaarheid in het achterhoofd, zijn primaire doel is om een specifieke taak te volbrengen.

Niet-modificeerbare code

Dit concept is gelukkig veel eenvoudiger en eenvoudiger uit te leggen. Het korte en eenvoudige antwoord is dat frameworks een hoop code genereren en voor het grootste deel raak je die code niet aan.

Terugkomend op Rails zoals eerder uitgelegd, over het algemeen besteedt een ontwikkelaar het grootste deel van zijn tijd aan het werken aan de app-map. De ontwikkelaar zal over het algemeen niet veranderen of verwijderen van de vooraf geschreven code.

Plaats een reactie