Könyvtárak vs. keretrendszerek – mi a különbség?

A kódkönyvtárat a Wikipédia oldala a következőképpen definiálja:

“A számítástechnikában a könyvtár a számítógépes programok által használt, nem tárolható erőforrások gyűjteménye, gyakran szoftverfejlesztéshez. Ezek lehetnek konfigurációs adatok, dokumentáció, súgóadatok, üzenetsablonok, előre megírt kód és alprogramok, osztályok, értékek vagy típusspecifikációk.”

Ezt összehasonlítva a keretrendszer definíciójával:

“A számítógépes programozásban a szoftver keretrendszer egy olyan absztrakció, amelyben az általános funkciókat biztosító szoftvereket további felhasználó által írt kóddal szelektíven módosítani lehet, így alkalmazásspecifikus szoftvereket biztosítva.

Az alkalmazások építésének és telepítésének szabványos módját biztosítja, és olyan univerzális, újrafelhasználható szoftverkörnyezet, amely egy nagyobb szoftverplatform részeként meghatározott funkciókat biztosít a szoftveralkalmazások, termékek és megoldások fejlesztésének megkönnyítése érdekében.”

Ez még sok kibogoznivaló, de ha már dolgozott mindkettővel, akkor valószínűleg már látja, hogy általában egy kódkönyvtárat arra használnak, hogy megoldjanak egy konkrét problémát vagy hozzáadjanak egy konkrét funkciót a programhoz.

A keretrendszer ezzel szemben valami sokkal általánosabbat és újrafelhasználhatóbbat biztosít. Ha tovább olvasod a Wikipédia bejegyzését, észreveheted, hogy három dolog választja el a keretrendszert a könyvtáraktól.

Kontrollváltozat

A könyvtárak csatlakoznak a kódodhoz, a kódod pedig a keretrendszerhez.

A keretrendszer és a könyvtár közötti első nagy különbség az, hogy ki irányítja a fejlesztési folyamatot.

A kódkönyvtár esetében a fejlesztő általában akkor hívja meg a könyvtárat, amikor úgy érzi, hogy ez szükséges. Egy keretrendszer általában megköveteli, hogy a fejlesztő teljesen belemerüljön a munkafolyamatba.

Az eredmény gyakran olyan érzés, mintha nem a fejlesztő, hanem a keretrendszer irányítaná a fejlesztési folyamatot. Ez az irányítás megfordítása! Ezt általában a következők valamelyik variációjaként szokták leegyszerűsíteni:

  • Könyvtár: Hívjon minket, hogy elvégezzük a munkát.
  • Keretrendszer:

A kontrollnak ez az inverziója miatt a keretrendszerek sokkal véleményesebbek, és ezért is képesek olyan sokat tenni a fejlesztőkért.

A véleményes azok számára, akik csodálkoznak, azt jelenti, hogy a keretrendszerek sok döntést hoznak a kód megírásának módjáról, a fájlok helyéről, és esetleg még az említett fájlok nevéről is.

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. Amikor egy új projektet hoz létre a Ruby on Rails segítségével, számos mappát és fájlt generál rengeteg előre megírt kóddal.

A fejlesztő munkájának nagy részét valószínűleg az app mappában végzi (ez a modellek, nézetek, vezérlők almappáinak helye), de rengeteg más kód is van abban a Rails projektben, amely arra szolgál, hogy az alkalmazás futni tudjon.

Márpedig a Ruby on Railsnek van egy meghatározott munkafolyamata, amelynek követését elvárja. Amikor létrehozol egy User modellt a Railsben, feltételezi, hogy az egy UsersController modellhez van kötve.

A Rails azt akarja, hogy ezeket a fájlokat egy bizonyos módon nevezzük el (user.rb a modellhez és users_controller.rb a vezérlőhöz), és a megfelelő mappákban akarja őket.

A Rails munkafolyamatától való eltérés frusztrációt fog okozni, hogy hogyan és miért nem működik a kódod. 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.

Te döntöd el, hogy mikor és hol hívod meg a Chart.js-t, és bár igaz, hogy egy új diagram készítésekor ki kell töltened a mezőket (meg kell adnod a diagram típusát, a címkéket, a színeket stb.), ez nem irányítja a munkafolyamatodat.

A Chart.js csak a diagram rajzolásához szükséges információkkal törődik; a kódod többi része kevésbé érdekli.

Bővíthetőség

Az objektumorientált programozás egyik fontos fogalma a nyitott-zárt elv. A nyitott-zárt elv azt mondja ki, hogy a kód viselkedésének nyitottnak kell lennie a módosításra/bővítésre anélkül, hogy közvetlenül meg kellene változtatni.

Egy egyszerű példa erre az osztályok öröklése, amely lehetővé teszi, hogy egy alosztály hozzáadhassa a számára szükséges funkciókat és funkciókat anélkül, hogy a szülő osztály kódját közvetlenül meg kellene változtatni.

A bővíthetőség lehetővé teszi a fejlesztő számára, hogy új funkciókat adjon egy keretrendszerhez, vagy a meglévő funkciók viselkedését a saját igényeihez igazítsa a forráskód módosítása nélkül.

A jó keretrendszerek a bővíthetőség szem előtt tartásával épülnek. Biztosítják az általános alkalmazások fejlesztéséhez szükséges általános funkciókat, de nyitva hagyják magukat az adott alkalmazáshoz szükséges specifikus kiegészítések és módosítások előtt.

Ha egy keretrendszer nem lenne bővíthető, akkor meglehetősen korlátozott lenne a funkcionalitása, és ez sokkal kevésbé vonzóvá tenné a tanulását.

A fenti példákat folytatva, a Ruby on Rails keretrendszerhez számos bővítmény létezik, amelyekkel további funkciókat, például felhasználói hitelesítést lehet hozzáadni.

Ha a Rails nem rendelkezne ilyen bővítményekkel, akkor ez komolyan akadályozná, hogy mit lehet vele létrehozni. Hogy igazságos legyek, a Chart.js is számos bővítménnyel és kiterjesztéssel rendelkezik. Ezek olyan dolgokat tesznek lehetővé, mint például további diagramtípusok rajzolása.

A különbség itt sokkal kevésbé látható, azonban mivel a keretrendszerek általános funkcionalitást biztosítanak, a bővíthetőséget szem előtt tartva kell megépíteni őket, hogy alkalmazásspecifikus funkciókat lehessen megvalósítani.

A könyvtárat nem feltétlenül a bővíthetőséget szem előtt tartva kell megépíteni, elsődleges célja egy konkrét feladat elvégzése.

Nem módosítható kód

Ezt a fogalmat szerencsére sokkal könnyebb és egyszerűbb elmagyarázni. A rövid és egyszerű válasz az, hogy a keretrendszerek egy csomó kódot generálnak, és a legtöbbször nem nyúlunk ehhez a kódhoz.

Az előbb elmagyarázott Railshez visszatérve, általában egy fejlesztő az ideje nagy részét az alkalmazás mappáján dolgozik. A fejlesztő általában nem fogja megváltoztatni vagy törölni az előre megírt kódot.

Szólj hozzá!