Knihovny vs. rámce – jaký je mezi nimi rozdíl?

Stránka Wikipedie definuje knihovnu kódu takto:

„V informatice je knihovna soubor nevolatilních zdrojů používaných počítačovými programy, často pro vývoj softwaru. Mohou zahrnovat konfigurační data, dokumentaci, údaje nápovědy, šablony zpráv, předpřipravený kód a podprogramy, třídy, hodnoty nebo specifikace typů.“

V porovnání s definicí frameworku:

„V počítačovém programování je softwarový framework abstrakce, ve které lze software poskytující obecnou funkčnost selektivně měnit dalším kódem napsaným uživatelem, a poskytovat tak software specifický pro danou aplikaci.

Představuje standardní způsob vytváření a nasazování aplikací a je univerzálním, opakovaně použitelným softwarovým prostředím, které poskytuje konkrétní funkce jako součást větší softwarové platformy usnadňující vývoj softwarových aplikací, produktů a řešení.“

Je toho hodně k rozbalení, ale pokud jste pracovali s obojím, pravděpodobně už chápete, že obecně se knihovna kódu používá k řešení konkrétního problému nebo k přidání konkrétní funkce do programu.

Framework naproti tomu poskytuje něco mnohem obecnějšího a opakovaně použitelného. Pokud budete pokračovat ve čtení hesla ve Wikipedii, zjistíte, že framework od knihovny dělí tři věci:

Inverze řízení

Knihovny se zapojují do vašeho kódu, Váš kód se zapojuje do frameworku.

První zásadní rozdíl mezi frameworkem a knihovnou spočívá v tom, kdo řídí proces vývoje.

U knihovny kódu vývojář zpravidla volá knihovnu, kdykoli to považuje za vhodné. Framework obecně vyžaduje, aby byl vývojář plně ponořen do jeho pracovního postupu.

V důsledku toho se často zdá, že proces vývoje řídí spíše framework než vývojář. To je inverze kontroly! Běžně se to zjednodušuje jako některá z následujících variant:

  • Knihovna:
  • Rámec: Zavolejte nám, abychom udělali práci.
  • Rámec: Zavolejte nám, abychom udělali práci:

Díky této inverzi kontroly jsou frameworky mnohem více názorově vyhraněné a také proto jsou schopny toho pro vývojáře tolik udělat.

Názorová vyhraněnost pro ty, které to zajímá, znamená, že frameworky dělají spoustu rozhodnutí týkajících se způsobu zápisu kódu, umístění souborů a případně i názvu zmíněných souborů.

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. Když vytvoříte nový projekt v Ruby on Rails, vygeneruje se mnoho složek a souborů se spoustou předpřipraveného kódu.

Většinu práce vývojář pravděpodobně odvede ve složce app (zde jsou umístěny podsložky modelů, pohledů a kontrolérů), ale v tomto projektu Rails je spousta dalšího kódu, který je určen k tomu, abyste mohli aplikaci spustit.

Ruby on Rails má navíc specifický pracovní postup, jehož dodržování od vás očekává. Když v systému Rails vytvoříte model User, předpokládá, že je svázán s modelem UsersController.

Rails chce tyto soubory pojmenovat určitým způsobem (user.rb pro model a users_controller.rb pro kontrolér) a chce je mít v příslušných složkách.

Odchýlení se od pracovního postupu Rails způsobí, že budete frustrováni tím, jak a proč váš kód nefunguje. 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.

Vy si vybíráte, kdy a kde Chart.js zavoláte, a i když je pravda, že při vytváření nového grafu musíte vyplnit pole (budete chtít určit typ grafu, popisky, barvy atd.), neovlivňuje to váš pracovní postup.

Chart.js se stará pouze o informace potřebné k vykreslení grafu; zbytek vašeho kódu ho může zajímat méně.

Rozšiřitelnost

Důležitým konceptem v objektově orientovaném programování je princip otevřeného-uzavřeného. Princip otevřeného-uzavřeného kódu říká, že chování kódu by mělo být otevřené pro změnu/rozšíření, aniž by bylo nutné jej přímo měnit.

Jednoduchým příkladem je dědičnost ve třídách, která umožňuje podtřídě přidávat potřebné funkce a vlastnosti, aniž by bylo nutné přímo měnit kód v nadřazené třídě.

Rozšiřitelnost umožňuje vývojáři přidávat do frameworku nové funkce nebo přizpůsobovat chování stávajících funkcí svým potřebám, aniž by musel měnit zdrojový kód.

Dobré frameworky jsou vytvářeny s ohledem na rozšiřitelnost. Poskytují obecné funkce potřebné pro vývoj obecné aplikace, ale nechávají se otevřené pro specifická doplnění a změny potřebné pro konkrétní aplikaci.

Pokud by framework nebyl rozšiřitelný, byl by ve svých funkcích poměrně omezený, což by ho činilo mnohem méně atraktivním pro učení.

Podle výše uvedených příkladů existuje několik rozšíření pro framework Ruby on Rails, která přidávají další funkce, například ověřování uživatelů.

Pokud by framework Rails tato rozšíření postrádal, značně by to omezovalo to, co byste pomocí něj mohli vytvořit. Abychom byli spravedliví, Chart.js má také mnoho zásuvných modulů a rozšíření. Ty umožňují například kreslení dalších typů grafů.

Rozdíl je zde však mnohem méně viditelný, protože frameworky poskytují obecnou funkčnost, měly by být vytvářeny s ohledem na rozšiřitelnost, aby bylo možné implementovat funkce specifické pro danou aplikaci.

Knihovna nemusí být nutně vytvářena s ohledem na rozšiřitelnost, jejím primárním účelem je splnit konkrétní úkol.

Nezměnitelný kód

Tento koncept je naštěstí mnohem snazší a jednodušší vysvětlit. Stručná a jednoduchá odpověď zní: frameworky vygenerují spoustu kódu a většinou se tohoto kódu nedotýkáte.

Pokud se vrátíme k dříve vysvětlenému systému Rails, vývojář obecně tráví většinu času prací na složce aplikace. Vývojář zpravidla nebude měnit ani mazat předem napsaný kód.

Napsat komentář