Softwarový rámec - Software framework

„Framework (informatika)“ přeadresuje tady. Pro jiná použití, viz Framework (disambiguation) .

V programování počítače , je software rámec je abstrakcí , ve které program poskytuje obecnou funkcí, může být selektivně měnit další uživatelské psaný kódem, čímž poskytuje aplikačně specifický software. Poskytuje 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 pro usnadnění vývoje softwarových aplikací , produktů a řešení. Softwarové rámce mohou zahrnovat podpůrné programy, překladače, knihovny kódů, sady nástrojů a rozhraní API (Application Programming Interface), které spojují všechny různé komponenty a umožňují vývoj projektu nebo systému .

Rámce mají klíčové rozlišovací funkce, které je oddělují od běžných knihoven :

  • inverze ovládání : V rámci, na rozdíl od knihoven nebo standardních uživatelských aplikací, není celkový tok řízení programudiktován volajícím, ale rámcem. Toho je obvykle dosaženo pomocí šablony metody šablony .
  • výchozí chování : To může být poskytnuto s invariantními metodami šablony metody šablony v abstraktní třídě, která je poskytována rámcem.
  • rozšiřitelnost : Uživatel může rámec rozšířit - obvykle selektivním přepsáním - nebo mohou programátoři přidat specializovaný uživatelský kód, který poskytne konkrétní funkce. Toho je obvykle dosaženo metodou hook v podtřídě, která přepíše metodu šablony v nadtřídě.
  • nemodifikovatelný kód rámce : Kód rámce obecně nemá být upravován, zatímco přijímá uživatelem implementovaná rozšíření. Jinými slovy, uživatelé mohou rámec rozšířit, ale nemohou upravit jeho kód.

Zdůvodnění

Cílem návrhářů softwarových rámců je usnadnit vývoj softwaru tím, že návrhářům a programátorům umožní věnovat svůj čas plnění softwarových požadavků, než aby se zabývali standardnějšími podrobnostmi o nízké úrovni poskytování pracovního systému, čímž se zkrátí celková doba vývoje. Například tým využívající webový framework k vývoji bankovního webu se může soustředit na psaní kódu konkrétně pro bankovnictví, nikoli na mechaniku zpracování požadavků a správu stavu .

Rámce často zvětšují velikost programů, což je jev nazývaný „ bloat kódu “. Vzhledem k potřebám aplikací řízených poptávkou zákazníků někdy v produktu skončí jak konkurenční, tak doplňkové rámce. Navíc vzhledem ke složitosti jejich API nemusí být dosaženo zamýšleného zkrácení celkového času vývoje kvůli potřebě strávit další čas učením se používat rámec; tato kritika je jasně platná, když vývojový personál poprvé narazí na speciální nebo nový rámec. Není-li takový rámec použit v následných pracovních úkolech, může čas investovaný do osvojení rámce stát více než účelově napsaný kód známý pracovníkům projektu; mnoho programátorů uchovává kopie užitečného standardu pro běžné potřeby.

Jakmile se však naučíte rámec, budoucí projekty mohou být rychlejší a snadněji dokončitelné; koncepcí rámce je vytvořit sadu řešení, která bude vyhovovat všem, a při znalosti by se produkce kódu měla logicky zvýšit. Neexistují žádná taková tvrzení o velikosti kódu, který je nakonec součástí výstupního produktu, ani o jeho relativní účinnosti a stručnosti. Použití jakéhokoli řešení knihovny nutně přitahuje doplňky a nevyužitá cizí aktiva, pokud software není linkerem kompilátoru a objektu, který vytváří těsný (malý, plně kontrolovaný a specifikovaný) spustitelný modul.

Problém pokračuje, ale více než deset let zkušeností v oboru ukázalo, že nejefektivnějšími rámci jsou ty, které se vyvíjejí z přeformátování společného kódu podniku, namísto použití obecného „univerzálního řešení pro všechny“. "rámec vyvinutý třetími stranami pro obecné účely." Příkladem může být to, jak se uživatelské rozhraní v takovém balíčku aplikací, jako je kancelářský balík, rozrůstá o společný vzhled, dojem a atributy a metody sdílení dat, protože kdysi nesourodé sdružené aplikace rostou sjednocené do sady, která je užší a menší; novější/vyvinutá sada může být produkt, který sdílí integrované knihovny nástrojů a uživatelská rozhraní.

Tento trend kontroverze přináší důležitý problém rámců. Vytváření elegantního rámce ve srovnání s rámcem, který pouze řeší problém, je stále spíše řemeslo než věda. „Softwarová elegance “ znamená srozumitelnost, stručnost a malé plýtvání (nadbytečné nebo cizí funkce, z nichž většina je definována uživatelem). U těch rámců, které generují kód, by například „elegance“ znamenala vytvoření kódu, který je pro rozumně informovaného programátora čistý a srozumitelný (a který je tedy snadno modifikovatelný), ve srovnání s rámcem, který pouze generuje správný kód. Problém elegance je důvod, proč relativně málo softwarových rámců obstálo ve zkoušce času: nejlepší rámce se dokázaly elegantně vyvíjet s tím, jak se pokročila základní technologie, na které byly postaveny. I když se mnoho takových balíčků vyvinulo, udrží si původní možnosti nadýmající konečný software, protože jinak nahrazené metody byly zachovány souběžně s novějšími metodami.

Příklady

Python Powered.png

Softwarové rámce obvykle obsahují značné množství úklidových služeb a obslužný kód, aby pomohly zavést uživatelské aplikace, ale obecně se zaměřují na konkrétní problémové domény, například:

Architektura

Podle Pree se softwarové rámce skládají ze zmrazených míst a horkých míst . Zamrzlá místa definují celkovou architekturu softwarového systému, tj. Jeho základní součásti a vztahy mezi nimi. Ty zůstávají beze změny (zmrazené) při jakékoli instanci aplikačního rámce. Aktivní místa představují ty části, kde programátoři používající rámec přidávají vlastní kód, aby přidali funkce specifické pro svůj vlastní projekt.

V objektově orientovaném prostředí se rámec skládá z abstraktních a konkrétních tříd . Vytvoření instance takového rámce spočívá ve vytváření a podtřídě stávajících tříd.

Potřebnou funkcionalitu lze implementovat pomocí šablony metody šablony, ve které jsou zmrazená místa známá jako invariantní metody a horká místa známá jako variantní nebo hákové metody. Invariantní metody v nadtřídě poskytují výchozí chování, zatímco metody zavěšení v každé podtřídě poskytují vlastní chování.

Při vývoji konkrétního softwarového systému se softwarovým rámcem vývojáři využívají horká místa podle konkrétních potřeb a požadavků systému. Softwarové rámce se opírají o hollywoodský princip : „Nevolejte nám, zavoláme vám.“ To znamená, že uživatelem definované třídy (například nové podtřídy) přijímají zprávy z předdefinovaných tříd rozhraní. Vývojáři to obvykle řeší implementací abstraktních metod nadtřídy .

Viz také

Reference