男人喝什么汤补肾壮阳
Aspektově orientované programování (zkracováno na AOP, z anglického Aspect Oriented Programming) je programovací paradigma, které má za cíl zvy?it modularitu programu. Pokou?í se rozdělit program na jasné ?ásti, které se mezi sebou co nejméně p?ekryvají svou funkcionalitou. AOP se za?alo hojně pou?ívat zejména v roce 2004.
úvod
[editovat | editovat zdroj]Vět?ina programovacích paradigmat podporuje ur?itou úroveň seskupení a zapouzd?ení dat do samostatnych, nezávislych subjekt?. Některé v?ak vzdorují této formě implementace a jsou nazyvány pr??ezové problémy (crosscutting concerns), proto?e se nachází ve více ?ástech programu. AOP má za cíl nahradit v kódu opakující se ?innosti, vzorovym p?íkladem pr??ezového problému je logování, proto?e se tyká ka?dé jednotlivé logované ?ásti programu. Logování tedy pro?ezává v?echny logované t?ídy, metody i procedury. V?echny implementace AOP mají nějaké pr??ezové vyrazy, které zapouzd?í danou ?innost na konkrétním místě. Rozdíl mezi implementacemi spo?ívá v náro?nosti, bezpe?nosti a pou?itelnosti poskytnutych konstrukcí. AspectJ má ?adu těchto vyraz? a zapouzd?uje je ve speciální t?ídě, zvané aspekt. Aspekt m??e upravit chování základního kódu (neaspektové ?ásti programu) pou?itím advice (dodate?né chování) v r?znych joinpoints (body ve struktu?e programu), zvany pointcut (soubor joinpoint?, pro které je spou?těna stejná advice). Aspekt také m??e dělat binárně kompatibilní strukturální změny jinych t?íd, co? je nap?íklad p?idání ?len? nebo rodi??.
Historie
[editovat | editovat zdroj]Aspektově orientované programování má několik p?ímych p?edch?dc?: reflexe a metaobjektové protokoly, objektové programování, filtry a adaptivní programování.
Tento koncept vymyslel Gregor Kiczales s kolegy v Xerox PARC. Stejny tym vyvinul i první a zatím nejpou?ívaněj?í aspektově orientovany jazyk AspectJ.
Microsoft Transaction Server je pova?ován za první hlavní pou?ití AOP následovany Enterprise Java Beans.
Typy aspektově orientovaného programování
[editovat | editovat zdroj]AOP se dá rozdělit na statické a dynamické. Statické AOP poskytuje nap?íklad AspectJ a dynamické Spring Framework.
Statické AOP
[editovat | editovat zdroj]Statické AOP je rychlej?í ne? dynamické, jeliko? weaving (proces vkládání aspekt? do aplikace) probíhá ji? p?i buildu aplikace, p?ibyvá zde dal?í krok, av?ak kód AOP ji? p?i běhu aplikace nelze měnit. Pot?ebujeme-li tedy udělat jakoukoli změnu za běhu aplikace, jsme nuceni k opětovné kompilaci celé aplikace. Statické AOP se pou?ívá nap?íklad v ji? zmiňovaném AspectJ.
Dynamické AOP
[editovat | editovat zdroj]Dynamické AOP je sice oproti statickému AOP pomalej?í, ale m??eme měnit kód zcela nezávisle na aplikaci. Změny v AOP tedy neznamenají nutnou opětovnou kompilaci celé aplikace. Je to zp?sobené tím, ?e u dynamickych AOP probíhá weaving a? p?i běhu aplikace. U r?znych implementací je toho dosa?eno za pomoci r?znych technik, nej?astěji je v?ak pou?íváno proxy pro ka?dy objekt, ktery vyu?ívá aspekty.
Motivace a základní koncepty
[editovat | editovat zdroj]Aspekt je typicky rozptylen jako kód, tak?e není zcela lehké ho pochopit a udr?ovat. Aspekt je rozptylen na základě funkce (nap?íklad logování) a je rozlo?en do několika nesouvisejících funkcí, které by mohly pou?ívat jeho funkce, p?ípadně ve zcela nesouvisejících systémech, r?znych zdrojovych jazycích atd. To znamená, ?e ke změně logování m??e vy?adovat modifikaci v?ech doty?nych modul?. Aspekty nejsou “zamotané” pouze s hlavními funkcemi systému, ve kterém jsou vyjád?ené, ale i mezi sebou navzájem. Nap?íklad si p?edstavme bankovní aplikaci s koncep?ně velmi jednoduchou metodou na p?evod ?ástky z jednoho ú?tu na druhy:[1]
void transfer(Account fromAcc, Account toAcc, int amount) throws Exception {
if (fromAcc.getBalance() < amount)
throw new InsufficientFundsException();
fromAcc.withdraw(amount);
toAcc.deposit(amount);
}
Nicméně, tato metoda pro p?evod peněz mezi ú?ty je velice vzdálená reálnym bankovním aplikacím, jeliko?, kv?li bezpe?nosti, musíme ově?it, zda má aktuální u?ivatel autorizaci k provedení této operace. Musíme také uzav?ít tuto operaci do databázové transakce, abychom p?ede?li nekonzistenci dat. Zjednodu?ená verze s těmito novymi koncerny (problémy) by mohla vypadat nějak takto:
void transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) throws Exception {
logger.info("Transferring money…");
if (!isUserAuthorised(user, fromAcc)) {
logger.info("User has no permission.");
throw new UnauthorisedUserException();
}
if (fromAcc.getBalance() < amount) {
logger.info("Insufficient funds.");
throw new InsufficientFundsException();
}
fromAcc.withdraw(amount);
toAcc.deposit(amount);
database.commitChanges(); // Atomic operation.
logger.info("Transaction successful.");
}
Kód ji? není tak jednoduchy a elegantní, jeliko? jsme p?idali r?zné dal?í koncerny (problémy) k základní funkcionalitě (někdy zvané koncern obchodní logiky). Transakce, zabezpe?ení a logování jsou p?íklady pr??ezovych problém?. Nyní si p?edstavme, co se stane, kdy? najednou pot?ebujeme změnit (nap?íklad) bezpe?nostní schéma pro danou aplikaci. V sou?asné verzi programu jsou operace tykající se zabezpe?ení “rozesety” v mnoha metodách, a tak by změna vy?adovala zna?né úsilí. AOP se sna?í tento problém vy?e?it tím, ?e programátor vyjád?í pr??ezové problémy v samostatnych modulech zvanych aspekty. Aspekty mohou obsahovat advice (kód spojeny s ur?itymi body v programu) a inter-type declarations (roz?í?ení deklarace t?íd). Nap?íklad bezpe?nostní modul m??e obsahovat advice, ktery provádí bezpe?nostní kontrolu p?ed vstupem do bankovního ú?tu. Pointcut definuje dobu (join points), kdy je mo?né získat p?ístup k bankovnímu ú?tu a kód v těle advice ur?uje, jak je bezpe?nostní kontrola implementována. To je zp?sob, jak mohou byt kontrola a místo udr?ovány na jednom místě. Dobry pointcut, také m??e p?edvídat pozděj?í programové změny, tak?e pokud jiny vyvojá? vytvo?í novou metodu pro p?ístup k bankovnímu ú?tu, advice se bude vztahovat i na nové metody, p?i jejich provádění. Tak?e takto se pro vy?e uvedeny p?íklad provádí záznam v aspektu:
aspect Logger {
void Bank.transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) {
logger.info("Transferring money…");
}
void Bank.getMoneyBack(User user, int transactionId, Logger logger) {
logger.info("User requested money back.");
}
// Other crosscutting code.
}
Join point modely (JPM)
[editovat | editovat zdroj]Zp?sob spolupráce aspektu s programem je definován v join point modelu (z anglického join point model). JPM definuje t?i věci: Join points - místa, do kterych je mo?né do kódu vlo?it logiku pomocí AOP Advice - kód, ktery se spou?tí v join pointu, m??e se spou?tět p?ed (before) i za (after) join pointem Pointcut - je soubor join point?, ve kterych je spu?těna stejná advice
Srovnání s jinymi programovacími paradigmaty
[editovat | editovat zdroj]Aspekty vycházejí z objektově orientovaného programování (OOP). AOP jazyky nabízí podobné funkce jako metaobject protokoly. Aspekty úzce souvisí s programovacími koncepty jako subjekty, mixiny a delegace. Ji? od roku 1970 vyvojá?i pou?ívali formy odposlechu (interception) a záplatování (dispatch-patching), které se podobají některym ze zp?sob? implementace pro AOP, ale nikdy nebyly ozna?ovány jako cross cutting specifikace a sepsány na jednom místě. Návrhá?i zva?ovali i jiné zp?soby, jak dosáhnout odděleného kódu, jako jsou nap?íklad díl?í typy (partial types) v C#, těmto p?ístup?m v?ak chybí kvantifika?ní mechanismus, ktery umo?ňuje propojení několika join point? s jednou deklarací.
