Slovník pojmů

Knihovna

Knihovna řeší opakovaně použitelnou funkci a aplikace ji přímo volá. Balíček je způsob distribuce a framework řídí tok aplikace – tyto pojmy se často potkávají, ale nejsou totožné.

Stručná definice

Použitelný kód s vlastním veřejným kontraktem.

Knihovna může nabízet HTTP klienta, práci s UUID, logování, validaci nebo testování. Její veřejné API je dohoda s aplikací: určuje dostupné třídy, metody, datové typy, výjimky a pravidla kompatibility.

V PHP se knihovny běžně distribuují jako Composer balíčky a načítají přes PSR-4 autoloader. Balíček však může obsahovat i CLI nástroj, plugin či frameworkovou komponentu; slova balíček a knihovna proto nejsou přesná synonyma.

Jaký problém řeší

Zamezuje opakovanému řešení stejné technické úlohy

Dobrá knihovna přináší udržovaný kontrakt pro problém, který by vlastní kód řešil hůře nebo opakovaně.

HTTP klient pro externí API
logování a korelační identifikátory
práci s UUID, časem nebo datovým formátem
validaci, serializaci či kryptografické funkce
testovací frameworky a nástroje pro statickou analýzu

Praktický příklad

Composer zpřístupní deklarovanou knihovnu autoloaderem

PHP aplikace deklaruje závislost v composer.json. Composer vyřeší její verzi včetně tranzitivních závislostí, zaznamená stav do composer.lock a vytvoří autoloader. Aplikace pak pracuje jen s veřejným API knihovny.

Samotné načtení autoloaderu není kontrola bezpečnosti ani záruka kompatibility. Změna knihovny patří do review společně s verzí, changelogem, testy a dopadem na aplikaci.

require __DIR__ . '/vendor/autoload.php';

// Aplikace používá veřejné API nainstalované knihovny.

Jak funguje

Aplikace volá kontrakt, knihovna skrývá implementaci

Textový diagram: aplikace → veřejné API knihovny → interní implementace → výsledek nebo výjimka.

Volba problému Tým vyhodnotí, zda je vlastní malý kód či externí knihovna dlouhodobě vhodnější.
Deklarace závislosti Balíček se zapíše do Composeru s podporovanou verzí a potřebami platformy.
Instalace a autoloading Composer nainstaluje uzamčené verze a vytvoří mapování tříd.
Použití veřejného API Aplikace volá zdokumentovaný kontrakt, nikoli interní třídy, které se mohou měnit.
Údržba Aktualizace probíhá řízeně s testy, posouzením kompatibility a bezpečnostních dopadů.

Důležité pojmy

Veřejný kontrakt, verze a závislosti.

Přínos knihovny závisí na stabilitě kontraktu i schopnosti ji bezpečně udržovat.

Veřejné API

Třídy, funkce, rozhraní a výjimky určené uživatelům knihovny. Interní části nemají být neoficiálním základem aplikace.

Balíček a závislosti

Balíček je distribuční jednotka a může mít vlastní přímé i tranzitivní závislosti. Každá rozšiřuje údržbový a bezpečnostní povrch.

Verzování

Semantic versioning pomáhá popsat kompatibilitu, ale není absolutní záruka. Změnu je vždy potřeba ověřit v kontextu aplikace.

Autoloading

PSR-4 mapuje namespace na adresáře a brání ručnímu require jednotlivých tříd.

Dokumentace a licence

Před použitím je vhodné posoudit podporu, zabezpečení, licenci, aktivitu údržby a srozumitelnost dokumentace.

Vztah k podobným pojmům

Knihovna není aplikace ani služba dostupná přes síť.

Rozlišení pomáhá správně volit závislost i její hranici.

Framework: Framework volá kód aplikace v určeném lifecycle; knihovnu volá aplikace pro konkrétní funkci.
Composer balíček: Je distribuční jednotka. Může obsahovat knihovnu, ale i nástroj, plugin nebo framework.
API služba: Je dostupná přes síť a má provozní kontrakt. Knihovna běží přímo uvnitř procesu aplikace.
Interní modul: Může sdílet strukturu knihovny, ale není automaticky samostatně distribuovaným veřejným balíčkem.

Výhody a omezení

Znovupoužití šetří kód, ale přidává závislost.

Přínosy

ověřená funkčnost pro opakující se technický problém
jasnější rozhraní mezi částmi kódu
sdílená údržba a opravy v několika projektech
standardní instalace přes správce závislostí

Časté chyby

přidat balíček pro triviální funkci bez údržbové hodnoty
volat nezdokumentované interní třídy knihovny
aktualizovat závislosti naslepo bez testů
předpokládat, že malá nebo populární knihovna je automaticky bezpečná

Kdy dává smysl

Když knihovna řeší skutečný opakovaný problém lépe než vlastní kód.

Knihovna je vhodná například pro standardní HTTP komunikaci, kryptografii, validaci nebo testování, kde je důležité známé chování a údržba. U krátké lokální transformace může být naopak čitelnější vlastní jednoduchý a otestovaný kód.

Rozhodnutí nezáleží jen na počtu řádků. Patří sem licence, podpora verzí PHP, bezpečnostní aktualizace, kompatibilita se systémem a schopnost týmu změnu závislosti udržovat.

Na co myslet

Každá závislost je součástí produktu.

Knihovny mají stejnou životnost jako kód, který na nich stojí.

hodnotit veřejné API, aktivitu údržby, licenci a podporované platformy
držet lock file aplikace ve verzovacím systému
aktualizovat závislosti v menších, kontrolovatelných změnách
spouštět testy a security kontrolu po změně závislostí
nepoužívat interní implementační detaily jako nezdokumentovaný kontrakt

Časté otázky

Knihovny bez záměn

Je Composer balíček vždy knihovna?

Ne. Balíček může obsahovat knihovnu, framework, CLI nástroj, plugin nebo jiný distribuovatelný software.

Jak se knihovna liší od frameworku?

Knihovnu aplikace obvykle volá. Framework řídí hlavní tok a v určeném momentu volá aplikační kód.

Proč verzovat composer.lock?

U aplikace zachytí konkrétní sadu závislostí, aby CI a produkce instalovaly stejný ověřený stav.

Kdy napsat malý vlastní kód?

Když je problém úzce vymezený a externí závislost by přinesla více údržby než ověřitelný jednoduchý kód.

Jak pracuji s PHP v praxi

Závislosti vybírám jako součást dlouhodobě udržovaného backendu.

V PHP projektech propojuji frameworkové komponenty, integrační knihovny a quality gates tak, aby byl jejich dopad čitelný a ověřitelný.

Jak používám PHP v praxi Nezávazně probrat projekt