Biblioteci vs. Cadre de lucru – Care este diferența?

Pagina Wikipedia pentru o bibliotecă de cod o definește astfel:

„În informatică, o bibliotecă este o colecție de resurse nevolatile folosite de programele de calculator, adesea pentru dezvoltarea de software. Acestea pot include date de configurare, documentație, date de ajutor, șabloane de mesaje, cod pre-scris și subrutine, clase, valori sau specificații de tip.”

În comparație cu definiția unui cadru:

„În programarea calculatoarelor, un cadru software este o abstractizare în care software-ul care oferă funcționalitate generică poate fi modificat selectiv prin cod suplimentar scris de utilizator, oferind astfel un software specific aplicației.

Acesta oferă o modalitate standard de a construi și implementa aplicații și este un mediu software universal, reutilizabil, care oferă o anumită funcționalitate ca parte a unei platforme software mai mari pentru a facilita dezvoltarea de aplicații, produse și soluții software.”

Există multe de despachetat aici, dar dacă ați lucrat cu ambele, probabil că puteți vedea deja că, în general, o bibliotecă de cod este utilizată pentru a rezolva o problemă specifică sau pentru a adăuga o caracteristică specifică programului dumneavoastră.

Un framework, pe de altă parte, vă oferă ceva mult mai generic și reutilizabil. Dacă veți continua să citiți intrarea din Wikipedia, veți observa că trei lucruri separă un framework de o bibliotecă.

Inversia controlului

Bibliotecile se conectează la codul dumneavoastră, Codul dumneavoastră se conectează la un framework.

Prima diferență majoră între un framework și o bibliotecă este cine deține controlul asupra procesului de dezvoltare.

Cu o bibliotecă de cod, un dezvoltator apelează în general la bibliotecă ori de câte ori consideră că este cazul. Un cadru necesită, în general, ca dezvoltatorul să fie complet imersat în fluxul său de lucru.

Ca urmare, adesea se simte ca și cum cadrul deține controlul asupra procesului de dezvoltare mai degrabă decât dezvoltatorul. Aceasta este o inversare a controlului! Acest lucru este în mod obișnuit simplificat ca o variantă a următoarelor:

  • Biblioteca: Sunați-ne pentru a face treaba.
  • Framework: Nu ne sunați voi, vă vom suna noi.

Din cauza acestei inversări a controlului, cadrele sunt mult mai opinate și, de asemenea, motivul pentru care sunt capabile să facă atât de multe pentru dezvoltatori.

Opinate pentru cei care se întreabă înseamnă că cadrele iau o mulțime de decizii cu privire la modul în care este scris codul, locația fișierelor și, eventual, chiar și numele fișierelor respective.

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. Atunci când creați un nou proiect cu Ruby on Rails, acesta va genera numeroase foldere și fișiere cu o mulțime de cod pre-scris.

Cei mai mulți dintre dezvoltatorii de aplicații vor lucra probabil în folderul app (acesta este locul unde se află subfolderele modelelor, vizualizărilor, controlorilor), dar există o mulțime de alte coduri în acel proiect Rails care sunt concepute pentru ca aplicația dvs. să funcționeze.

În plus, Ruby on Rails are un flux de lucru specific pe care se așteaptă să îl urmați. Atunci când creați un model User în Rails, acesta presupune că este legat de un UsersController.

Rails vrea ca aceste fișiere să fie numite într-un anumit fel (user.rb pentru model și users_controller.rb pentru controler) și le vrea în folderele lor respective.

Devierea de la fluxul de lucru al Rails vă va lăsa frustrați de modul și motivul pentru care codul dvs. nu funcționează. 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.

Voi alegeți când și unde să apelați Chart.js și, deși este adevărat că vi se cere să completați câmpuri atunci când creați o nouă diagramă (veți dori să specificați tipul de diagramă, etichetele, culorile etc.), aceasta nu vă controlează fluxul de lucru.

Chart.js se preocupă doar de informațiile necesare pentru a desena o diagramă; nu-i pasă deloc de restul codului vostru.

Extensibilitate

Un concept important în programarea orientată pe obiecte este principiul deschis-închis. Principiul deschis-închis afirmă că comportamentul codului ar trebui să fie deschis pentru a fi modificat/extinse fără ca acesta să trebuiască să fie modificat direct.

Un exemplu simplu este moștenirea în clase, care permite unei subclase să adauge funcționalitatea și caracteristicile necesare acesteia fără a fi nevoie vreodată să modifice direct codul din clasa părinte.

Extensibilitatea permite unui dezvoltator să adauge noi caracteristici la un framework sau să adapteze comportamentul caracteristicilor existente pentru a răspunde nevoilor sale fără a modifica codul sursă.

Bunele framework-uri sunt construite cu extensibilitatea în minte. Ele oferă funcționalitatea generică necesară pentru a dezvolta o aplicație generică, dar se lasă deschise la adăugiri și modificări specifice necesare pentru o aplicație specifică.

Dacă un framework nu ar fi extensibil, ar fi destul de limitat în funcționalitatea sa și acest lucru l-ar face mult mai puțin atractiv pentru a fi învățat.

Continuând cu exemplele de mai sus, există mai multe extensii pentru framework-ul Ruby on Rails pentru a adăuga caracteristici suplimentare, cum ar fi autentificarea utilizatorilor.

Dacă Rails nu ar avea aceste extensii, ar îngreuna grav ceea ce ați putea realiza cu ajutorul lui. Pentru a fi corect, Chart.js are, de asemenea, multe pluginuri și extensii. Acestea permit lucruri cum ar fi desenarea unor tipuri suplimentare de grafice.

Diferența aici este mult mai puțin vizibilă, totuși, deoarece framework-urile oferă funcționalități generale, acestea ar trebui construite cu extensibilitatea în minte, astfel încât să poată fi implementate caracteristici specifice aplicațiilor.

O bibliotecă nu trebuie neapărat să fie construită cu extensibilitatea în minte, scopul său principal este de a îndeplini o sarcină specifică.

Cod nemodificabil

Acest concept este, din fericire, mult mai ușor și mai simplu de explicat. Răspunsul scurt și simplu este că framework-urile vor genera o grămadă de cod și, în cea mai mare parte, nu vă atingeți de acel cod.

Răspunzând la Rails, așa cum am explicat anterior, în general, un dezvoltator își petrece cea mai mare parte a timpului lucrând la dosarul aplicației. În general, dezvoltatorul nu va modifica sau șterge codul pre-scris.

.

Lasă un comentariu