Bibliotek vs ramverk – vad är skillnaden?

På Wikipedias sida definieras ett kodbibliotek som:

”Inom datavetenskapen är ett bibliotek en samling icke-flyktiga resurser som används av dataprogram, ofta för programvaruutveckling. Dessa kan inkludera konfigurationsdata, dokumentation, hjälpdata, meddelandemallar, förskriven kod och underrutiner, klasser, värden eller typspecifikationer.”

Jämförtydligar detta med definitionen av ett ramverk:

”Inom dataprogrammering är ett mjukvaruramverk en abstraktion där mjukvara som tillhandahåller generisk funktionalitet selektivt kan förändras med hjälp av ytterligare användarskriven kod, och på så sätt tillhandahålla applikationsspecifik programvara.

Den tillhandahåller ett standardiserat sätt att bygga och distribuera program och är en universell, återanvändbar programvarumiljö som tillhandahåller särskild funktionalitet som en del av en större programvaruplattform för att underlätta utvecklingen av programvarutillämpningar, produkter och lösningar.”

Det finns mycket där att packa upp, men om du har arbetat med båda delarna kan du förmodligen redan se att ett kodbibliotek i allmänhet används för att lösa ett specifikt problem eller för att lägga till en specifik funktion i ditt program.

Ett ramverk, å andra sidan, förser dig med något som är mycket mer generiskt och återanvändbart. Om du fortsätter att läsa Wikipediaposten kommer du att märka att tre saker skiljer ett ramverk från ett bibliotek.

Inversion av kontroll

Bibliotek kopplas in i din kod, Din kod kopplas in i ett ramverk.

Den första stora skillnaden mellan ett ramverk och ett bibliotek är vem som har kontroll över utvecklingsprocessen.

Med ett kodbibliotek anropar en utvecklare generellt sett biblioteket närhelst han eller hon anser det lämpligt. Ett ramverk kräver i allmänhet att utvecklaren är helt nedsänkt i dess arbetsflöde.

Som ett resultat av detta känns det ofta som om ramverket har kontroll över utvecklingsprocessen snarare än utvecklaren. Detta är omvänd kontroll! Detta förenklas vanligen som någon variant av följande:

  • Library:
  • Framework: Ring oss för att få jobbet gjort.
  • Framework: Du får inte göra något:

Det är på grund av denna inversion av kontroll som ramverken är mycket mer åsiktsstyrda och också varför de kan göra så mycket för utvecklare.

Opsiktsstyrda för den som undrar betyder att ramverken fattar många beslut om hur koden skrivs, var filerna placeras och kanske till och med namnet på de nämnda filerna.

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. När du skapar ett nytt projekt med Ruby on Rails kommer det att generera många mappar och filer med massor av färdigskriven kod.

Det mesta av utvecklarens arbete kommer troligen att göras i mappen app (här finns undermapparna models, views, controllers), men det finns massor av annan kod i det där Rails-projektet som är utformad för att få din applikation att fungera.

För övrigt har Ruby on Rails ett specifikt arbetsflöde som det förväntar sig att du ska följa. När du skapar en User modell i Rails förutsätter den att den är knuten till en UsersController.

Rails vill att dessa filer ska heta på ett visst sätt (user.rb för modellen och users_controller.rb för styrenheten) och vill att de ska ligga i sina respektive mappar.

Om du avviker från Rails arbetsflöde kommer du att bli frustrerad över hur och varför din kod inte fungerar. 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.

Du väljer själv när och var du vill anropa Chart.js och även om det är sant att du måste fylla i fält när du skapar ett nytt diagram (du vill ange typ av diagram, etiketter, färger etc.) så kontrollerar det inte ditt arbetsflöde.

Chart.js bryr sig bara om den information som behövs för att rita ett diagram, den bryr sig inte alls om resten av din kod.

Utvidgbarhet

Ett viktigt begrepp inom objektorienterad programmering är open-closed principen. Enligt open-closed-principen ska kodens beteende vara öppet för att ändras/utökas utan att den behöver ändras direkt.

Ett enkelt exempel på detta är arv i klasser som gör det möjligt för en underklass att lägga till funktionalitet och nödvändiga funktioner utan att någonsin behöva ändra koden direkt i den överordnade klassen.

Extensibility gör det möjligt för en utvecklare att lägga till nya funktioner till ett ramverk eller skräddarsy beteendet hos befintliga funktioner för att tillgodose sina behov utan att ändra källkoden.

Goda ramverk är byggda med extensibility i åtanke. De tillhandahåller den generiska funktionalitet som behövs för att utveckla en generisk applikation men lämnar sig själva öppna för specifika tillägg och ändringar som är nödvändiga för en specifik applikation.

Om ett ramverk inte var utbyggbart skulle det vara ganska begränsat i sin funktionalitet och det skulle göra det mycket mindre attraktivt att lära sig.

För att hålla sig till exemplen ovan finns det flera tillägg för ramverket Ruby on Rails för att lägga till ytterligare funktioner, t.ex. användarautentisering.

Om Rails saknade dessa tillägg skulle det vara ett allvarligt hinder för vad du kan göra med hjälp av det. För att vara rättvis, Chart.js har också många plugins och tillägg. Dessa möjliggör saker som att rita ytterligare typer av diagram.

Skillnaden här är dock mycket mindre synlig, men eftersom ramverk tillhandahåller allmän funktionalitet bör de byggas med utbyggbarhet i åtanke så att app-specifika funktioner kan implementeras.

Ett bibliotek behöver inte nödvändigtvis byggas med utbyggbarhet i åtanke, dess primära syfte är att utföra en specifik uppgift.

Nej modifierbar kod

Det här konceptet är tack och lov mycket lättare och enklare att förklara. Det korta och enkla svaret är att ramverk kommer att generera en massa kod och för det mesta rör du inte den koden.

Om vi återgår till Rails som vi förklarade tidigare, spenderar en utvecklare i allmänhet den största delen av sin tid med att arbeta på app-mappen. Utvecklaren ändrar eller raderar i allmänhet inte den förskrivna koden.

Lämna en kommentar