Aspektus-orientált programozás (AOP)

A Wikipédiából, a szabad enciklopédiából
Ugrás a navigációhoz Ugrás a kereséshez


A számítástechnikában az aspektus-orientált programozás (Aspect-oriented programming: AOP) egy olyan programozási paradigma, amelynek az a célja, hogy növelje a modularitást azáltal, hogy lehetővé teszi a különböző területeket érintő problémák elkülönítését . Ez úgy történik, hogy további viselkedést ad a meglévő kódhoz (egy úgynevezett tanácsot), anélkül, hogy módosítaná magát a kódot. Ehelyett külön meghatározza, hogy melyik kódot módosítsa egy "pointcut" specifikációval, például "naplózza az összes függvényhívást, amikor a függvény neve „set”-tel kezdődik" . Ez lehetővé tesz olyan viselkedések hozzáadását a programhoz, amelyek nem játszanak központi szerepet az üzleti logikában, (mint például a naplózás), anélkül, hogy a funkcionalitás kódmagját összezavarná.

Az AOP magában foglalja a programozási módszereket és eszközöket, amelyek támogatják az problémák modulálását a forráskód szintjén, míg az aspektus-orientált szoftverfejlesztés egy egész mérnöki tudományágra utal.

Az aspektus-orientált programozás magában foglalja a program logikájának különálló részekre bontását (úgynevezett aggodalmak, kohéziós területek). Szinte minden programozási paradigma támogatja az aggodalmak bizonyos szintű csoportosítását és beágyazását különálló, független entitásokba azáltal, hogy absztrakciókat (pl. függvények, eljárások, modulok, osztályok, metódusok) biztosít, amelyek felhasználhatók ezeknek az aggodalmaknak a megvalósítására. Egyes aggodalmak több absztrakciót „átvágnak” egy programban, és dacolnak a megvalósítás ezen formáival. Ezeket az aggályokat átfogó, vagy horizontális aggályoknak nevezzük.

A naplózás egy átfogó problémára ad megoldást, mivel ez a stratégia szükségszerűen érinti a rendszer minden naplózott részét. A naplózás ezáltal átvágja az összes naplózott osztályt és metódust.

Minden AOP-implementáció rendelkezik néhány átfogó kifejezéssel, amelyek minden aggályt összefoglalnak. Az implementációk közötti különbség a rendelkezésre álló konstrukciók teljesítményében, biztonságában és használhatóságában rejlik. Például az elfogók, amelyek specifikálják a metódusokat a keresztmetszetek korlátozott formáinak kifejezésére, anélkül, hogy nagyban támogatnák a típusbiztonságot vagy a hibakeresést. Az AspectJ számos ilyen kifejezést tartalmaz, és egy speciális osztályba, egy aspektusba foglalja őket. Például egy aspektus megváltoztathatja az alapkód viselkedését (a program nem aspektusú része) azálta, hogy tanácsokat (további viselkedéseket) alkalmaz különböző csatlakozási pontokon (a programban lévő pontokon), amelyeket egy pontkivágásnak nevezett számszerűsítés által, vagy lekérdezésben határoznak meg (amely észleli, hogy egy adott csatlakozási pont egyezik-e). Egy aspektus binárisan kompatibilis szerkezeti változások végrehajtására is képes más osztályokban, például további tagok vagy szülők hozzáadásával.

Története[szerkesztés]

Az AOP-nak számos közvetlen elődje van - A1 és A2: reflexiós és metaobjektum protokollok, tárgyorientált programozás, kompozíciószűrés és adaptív programozás . [1]

Gregor Kiczales és munkatársai a Xerox PARC-nél kidolgozták az AOP explicit koncepcióját, és ezt követték az AspectJ AOP Java-bővítményével. Az IBM kutatócsoportja a nyelvi tervezési megközelítés helyett eszközszemléletű megközelítést követett, és 2001-ben javasolta a Hyper/J-t és a Concern Manipulation Environment-t, amelyek nem terjedtek el széles körben.

A Microsoft Transaction Server az AOP első jelentős alkalmazása, amelyet az Enterprise JavaBeans követ. [2] [3]

Motiváció és alapfogalmak[szerkesztés]

Jellemzően, ha egy aspektus szétszórt vagy szövevényes, mint a kód, megnehezíti annak megértését és fenntartását. A funkció (például a naplózás) miatt szétszórva van számos függvény között, amelyek használhatják a funkcióját, esetleg teljesen független rendszerekben is, különböző forrásnyelveken…stb. Ez azt jelenti, hogy a naplózás megváltoztatásához szükség lehet az összes érintett modul módosítására. Az aspektusok nemcsak a kifejeződésükre utaló rendszerek fő funkciójával, hanem egymással is összekuszálódnak. Ez azt jelenti, hogy egy aggály megváltoztatása magában foglalja az összes kusza aggály megértését, vagy valamilyen eszközt, amellyel a változások hatása következtetni lehet.

Vegyünk például egy banki alkalmazást, amely elvileg nagyon egyszerű módszerrel utal át összeget egyik számláról a másikra: [4]

void transfer(Account fromAcc, Account toAcc, int amount) throws Exception {
  if (fromAcc.getBalance() < amount)
      throw new InsufficientFundsException();

  fromAcc.withdraw(amount);
  toAcc.deposit(amount);
}

Ez az átviteli módszer azonban figyelmen kívül hagy bizonyos szempontokat, amelyeket egy telepített alkalmazásnak meg kell követelnie: hiányoznak a biztonsági ellenőrzések annak ellenőrzésére, hogy az aktuális felhasználó rendelkezik-e jogosultsággal a művelet végrehajtására; az adatbázis-tranzakciónak magába kell foglalnia a műveletet a véletlen adatvesztés megelőzése érdekében; diagnosztikához a műveletet naplózni kell a rendszernaplóba...stb. A példa kedvéért egy változat, amely az összes fentebb említett aggályt tartalmazza, valahogy így nézhet ki:

void transfer(Account fromAcc, Account toAcc, int amount, User user,
    Logger logger, Database database) 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.");
}

Ebben a példában más érdekek is összekeveredtek az alapvető funkciókkal (ezt néha üzleti logikai aggálynak is nevezik). A tranzakciók, a biztonság és a naplózás mind átfogó aggályokat példáznak.

Most nézzük meg, mi történne, ha hirtelen meg kellene változtatnunk (például) az alkalmazás biztonsági szempontjait. A program jelenlegi verziójában a biztonsággal kapcsolatos műveletek számos metódusban elszórtan jelennek meg, és egy ilyen változtatás komoly erőfeszítést igényel.

Az AOP megpróbálja megoldani ezt a problémát azáltal, hogy lehetővé teszi a programozó számára, hogy horizontális aggályait kifejezhesse önálló modulokban, amelyeket aspektusoknak nevezünk. Az aspektusok tanácsokat (a program meghatározott pontjaihoz kapcsolt kód), és típusközi deklarációkat (más osztályokhoz hozzáadott strukturális tagok) tartalmazhatnak. Például egy biztonsági modul tartalmazhat tanácsokat, amelyek végrehajtanak egy biztonsági ellenőrzést, mielőtt hozzáférnek a bankszámlához. A pointcut meghatározza azokat az időket (csatlakozási pontokat), amikor valaki hozzáférhet a számlához, a tanácsadó részben található kód pedig a biztonsági ellenőrzés végrehajtásának módját tartalmazza. Ebben az esetben az ellenőrzés és a helyek is egy helyen lesznek. Továbbá, egy jó pointcut előre jelezheti a későbbi programváltozásokat, így ha egy másik fejlesztő új metódust hoz létre, hogy hozzáférhessen a bankszámlához, akkor a tanács az új metódusra hivatkozik, amikor végrehajtja.

Tehát a fenti példa alapján a naplózás megvalósítására egy aspektusban így nézne ki:

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.
}

Gondolhatunk az AOP-ra, mint hibakereső eszköz, vagy felhasználói szintű eszköz. Tanácsot kell fenntartani azokra az esetekre, amikor nincs lehetőségünk megváltoztatni a funkciót (felhasználói szint), vagy nem szeretnénk megváltoztatni a funkciót a gyártási kódban (hibakeresés).

Csatlakozás pont modellek[szerkesztés]

Az aspektus-orientált nyelv tanácsokkal kapcsolatos komponense egy csatlakozási pont modellt (JPM) határoz meg.

A JPM három dolgot határoz meg:

  1. Amikor a tanács képes lefutni. Ezeket csatlakozási pontnak nevezik, mert ezek pontok egy futó programban, ahol össze lehet kapcsolni különböző hasznos viselkedéseket. A csatlakozási pontoknak megszokottnak és érthetőnek kell lenniük, hogy egy hétköznapi programozó számára is hasznos legyen. Stabilnak kell lennie a lényegtelen programmódosítások során is, hogy az aspektus is stabil maradjon az ilyen változtatások alatt. Sok AOP implementáció támogatja a metódusok végrehajtását és a mezőre történő hivatkozásokat, mint csatlakozási pontok.
  2. A csatlakozási pontok (pontvágások) megadásának (vagy számszerűsítésének) módja. A pontvágások határozzák meg, hogy vajon a megadott csatlakozási pontok megegyeznek-e. A legtöbb hasznos pointcut nyelv az alapnyelvhez hasonló szintaxist használ (pl. az AspectJ Java aláírásokat használ), és lehetővé teszi az újrafelhasználást elnevezéssel és kombinációval.
  3. Egy csatlakozási ponton futtatandó kód megadásának eszköze. Az ApectJs hívja ezt a tanácsot, és képes futtatni a csatlakozási pontok előtt, után és körülöttük. Egyes implementációk olyan dolgokat is támogatnak, mint például egy metódus definiálása egy aspektusban, vagy egy másik osztályban.

A csatlakozási pontok modelljei összehasonlíthatóak az alapján, hogy hogyan lett megadva a módjuk, a pontokon engedélyezett műveletek által, és a szerkezeti fejlesztések alapján.

Az AspectJ csatlakozási pont modellje[szerkesztés]

  • Az AspectJs csatlakozási pontja magában foglalja egy metódus vagy konstruktor hívását, végrehajtását, egy osztály vagy objektum inicializálását, egy mező olvasási és írási hozzáférését, kivételkezelést…stb. Nem tartalmazzák a ciklusokat, szuperhívásokat, a dobási záradékokat, többszöri utasításokat.
  • A pontvágásokat a primitív pontvágás kijelölők (PCD) kombinációi határozzák meg. A fajlagos PCD-k egy bizonyos típusi csatlakozási ponthoz illeszkednek (pl. metódus végrehajtás), és általában Java-szerű aláírást tekintenek bemenetként. Az egyik ilyen pontvágás így néz ki: execution(* set*(*)) Ez a pontvágás megegyezik egy metódus-végrehajtás csatlakozási ponttal, ha a metódus „set”-tel kezdődik, és pontosan egy, de bármilyen típusú argumentuma van. A „dinamikus” PCD-k ellenőrzik a futásidejű változókat és a kötési változókat. Például: this(Point) Ez a pontvágás akkor egyezik, ha az éppen végrehajtott objektum a Point osztály egy példánya. Ne feledje, hogy egy osztály minősítetlen neve használható a Java normál típusú keresésén keresztül. A „hatókör” PCD-k korlátozzák az összekapcsolási pont lexikális hatókörét. Például: within(com.company.*) Ez a pontvágás a com.company csomag bármely típusú csatlakozási pontjához illeszkedik. A * a helyettesítő karakterek egyik formája, amellyel sok minden egy aláírással párosítható. A pontvágások összeállíthatók és elnevezhetők újrafelhasználás céljából. Például: pointcut set() : execution(* set*(*) ) && this(Point) && within(com.company.*); Ez a pontmetszet megegyezik egy metódus-végrehajtási csatlakozási ponttal, ha a metódus neve „set”-tel kezdődik, és ez a Point típusú példány a com.company csomagban van. A set() paranccsal hivatkozhatunk rá.
  • ·Az advice (tanács) azt határozza meg, hogy egy csatlakozási ponton (előtt, után, körül) futtasson egy bizonyos kódot (,amely egy metódus kódjához hasonlóan van megadva). Az AOP futtató környezete automatikusan meghívja a Tanácsot, amikor a pontvágás megegyezik a csatlakozási ponttal. Például: after() : set() : { Display.update(); } Ez gyakorlatilag meghatározza: „ha a set() pontvágás megegyezik a csatlakozási ponttal, akkor futtassa a Display.update() kódot, az összekapcsolási pont befejezése után.”

Egyéb lehetséges csatlakozási pont modellek[szerkesztés]

Vannak más típusú JPM-ek (Join Points Model=Csatlakozási Pont Modell) is. Az összes tanácsadási nyelv meghatározható a JPM-jük alapján. Például az UML egy hipotetikus aspektus nyelve a követkető JPM-mel rendelkezhet:

  • A csatlakozási pontok mind modellelemek.
  • A pointcut logikai kifejezés, amely a modell elemeit kombinálja.
  • Ezeken a pontokon az affektus eszköze az összes illeszkedő csatlakozási pont vizualizálása.

A típusok közötti deklarációk[szerkesztés]

A típusok közötti deklarációk módot adnak a modulok szerkezetét érintő, átfogó aggályok kifejezésére. Ezeket nyílt osztályoknak és kiterjesztési metódusoknak is nevezik. Ez lehetővé teszi a programozók számára, hogy egy helyen deklarálják egy másik osztály tagjait vagy őseit, annak érdekében, hogy egy vonatkozásban egyesítsék az adott problémához kapcsolódó összes kódot. Például, ha egy programozó inkább a látogatók használatával valósította meg az átfogó megjelenítési-frissítési aggályt, akkor a látogatói mintát használó típusok közötti deklaráció így nézhet ki az AspectJ-ben:

  aspect DisplayUpdate {
    void Point.acceptVisitor(Visitor v) {
      v.visit(this);
    }
    // other crosscutting code...
  }

Ez a kódrészlet hozzáadja az acceptVisitor metódust a Point osztályhoz.

Követelmény, hogy minden strukturális kiegészítés kompatibilis legyen az eredeti osztállyal, hogy a meglévő osztály kliensei továbbra is működjenek, kivéve, ha az AOP implementáció elvárhatja, hogy minden klienst mindig vezéreljen.

Implementáció[szerkesztés]

Az AOP-programok kétféle módon befolyásolhatnak más programokat; az alapul szolgáló nyelvektől és a környezetektől függően:

  1. egy kombinált program készül, amely az eredeti nyelven van validálva, és nem lehet megkülönböztetni a közönséges programtól a végső értelmezőig
  2. a végső értelmezőt vagy környezetet frissítik, hogy megértsék és megvalósítsák az AOP funkciókat.

A környezet megváltoztatásának nehézsége azt jelenti, hogy a legtöbb megvalósítás kompatibilis kombinációs programokat hoz létre, az úgynevezett szövés programátalakításon keresztül. Egy aspektus szövő beolvassa az aspektus orientált kódot, és egy megfelelő objektum-orientált kódot állít elő az integrált aspektusokkal. Ugyanaz az AOP nyelv sokféle szövési módszerrel megvalósítható, így egy nyelv szemantikáját sosem szabad a szövés megvalósítása szempontjából értelmezni. A megvalósítás sebességét és a telepítés egyszerűségét befolyásolja az, hogy milyen kombinációs módszert alkalmaznak.

A rendszerek megvalósíthatják a forrásszintű szövést olyan előfeldolgozókkal, (ahogy a C++-t eredetileg a CFrontban valósították meg) amelyek hozzáférést igényelnek a program forrásfájljaihoz. Habár a Java jól definiált bináris formája lehetővé teszi a bájtkód szövők számára, hogy bármilyen Java programban dolgozhassanak .class-file formában. A bájtkód-szövők telepíthetők a felépítési folyamat során, vagy ha a szövési modell osztályonkénti, akkor az osztálybetöltés során lehet telepíteni. Az AspectJs 2001-ben forrásszintű szövéssel indult, 2002-ben egy osztályonkénti bájtkód-szövő jelent meg, majd 2005-ben az AspectWerkz integrációja után fejlett betöltési támogatást kínált.

Minden olyan megoldásnak, amely programokat futás közben kombinálja, biztosítaniuk kell azt, hogy megfelelően különválasszák őket a programozó elkülönített modelljétől. A Java bájtkód-támogatása lehetővé teszi az összetett forrásfájlok számára, hogy bármely hibakereső átlépjen egy megfelelően szövött .class fájlon a forrásszerkesztőben. Egyes harmadik féltől származó visszafejtők azonban nem tudják feldolgozni a szövött kódot, mert a Javac által előállított kódra számítanak, nem pedig a többi más nem támogatott bájtkód formára (lásd bővebben lentebb, a Kritika részben).

A telepítési időben történő szövés egy másik megközelítést kínál. [5] Ez alapvetően utófeldolgozást jelent, de a generált kód „foltozása” helyett ez a szövési megközelítés alosztályozza a meglévő osztályokat, így a metódusokat metódus-felülbírálással vezeti be. A meglévő osztályok érintetlenek maradnak még a program futása közben is, és minden létező eszköz (hibakeresők, profilozók, stb.) használható a fejlesztés során. Ehhez hasonló megközelítés már bevált számos Java EE alkalmazásszerver, például az IBM WebSphere megvalósításában.

Terminológia[szerkesztés]

Az aspektus-orientált programozásban használt szabványos terminológia a következőket foglalhatja magában:

Átfogó aggályok
Annak ellenére, hogy az OO modellben a legtöbb osztály egyedülálló, meghatározott funkciót lát el, gyakran közös, másodlagos követelményeket osztanak meg más osztályokkal. Például előfordulhat, hogy naplózást szeretnénk hozzáadni az adathozzáférési réteg osztályaihoz, valamint az UI réteg osztályaihoz, amikor egy szál belép vagy kilép egy metódusba. További aggályok vonatkozhatnak a biztonságra, például a hozzáférés-szabályozásra, vagy az információáramlás-szabályozásra. Bár minden osztálynak jelentősen eltérőek az elsődleges funkciói, a másodlagos funkciók végrehajtásához szükséges kódok gyakran megegyeznek.
Tanács
Ez azt a kiegészítő kódot jelenti, amit alkalmazni szeretnénk a meglévő modellünkre. A fentebb említett példánkban ez az a naplózási kód, amelyet akkor alkalmazunk, amikor egy szál ki-vagy belép a metódusba.
Pointcut
Az a kifejezés, amelyet az alkalmazás azon végrehajtási pontjára adnak meg, ahol az átfogó aggályt alkalmazni kell. A mi példánkban egy pontvágást akkor érünk el, amikor egy szál belép a metódusba, egy másik pontvágást pedig akkor ér el, amikor a szál kilép az adott metódusból.
Vonatkozás
A pointcut és a tanács kombinációját aspektusnak nevezzük. A fenti példában egy naplózási aspektust adunk hozzá az alkalmazásunkhoz egy pontvágás definiálásával, és a megfelelő tanácsok megadásával.

Összehasonlítás más programozási paradigmákkal[szerkesztés]

Az aspektusok az objektum-orientált programozásból és a számítási reflexióból alakultak ki. Az AOP nyelvek a metaobjektum protokollhoz hasonlóak, de kevesebb funkcióval rendelkeznek. Az aspektusok szorosan kapcsolódnak az olyan programozási koncepciókhoz, mint a tárgyak, mixinek, delegálás. Az aspektus orientált programozási paradigmák használatának további módjai közé tartozik a Kompozíciószűrők és a hiperszelet megközelítés. Körülbelül az 1970-es évek óta a fejlesztők olyan elfogási és feladás-foltozási formákat használnak, amelyek hasonlítanak az AOP néhány implementációs metódusaira, de ezeknek a szemantikájuk soha nem volt egy helyre írva, amelyet a keresztmetszeti specifikációk biztosítanak.

A fejlesztők alternatív módszereket kezdtek használni a kód szétválasztása érdekében, mint például a C# részleges típusait, de ezekből hiányzik a számszerűsítési mechanizmus, amely lehetővé tenné a kód csatlakozási pontjának elérését egyetlen deklaratív utasítással. 

Habár úgy tűnhet, hogy nincs összefüggés, a tesztelés alatt a „mocks” és a „stubs” használata megköveteli az AOP technikák használatát, mint például a tanácsok körül, és így tovább… Itt az együttműködő objektumok a teszt célját szolgálják, ami egy átfogó probléma. Így a különféle Mock Object keretrendszerek biztosítják ezeket a szolgáltatásokat. Például egy folyamat meghív egy szolgáltatást, az egyenlegösszeg lekérdezéséhez. A folyamat tesztje során az nem lényeges, hogy honnan származik az összeg, csak az, hogy a folyamat az összeget a követelményeknek megfelelően használja.

Örökbefogadási problémák[szerkesztés]

A programozóknak tudniuk kell olvasni a kódot, és meg is kell érteniük, hogy mi történik, a hibák megelőzésének érdekében. Még a megfelelő oktatás mellett is nehéz megérteni az átfogó problémákat, a program statikus szerkezetének, és dinamikus áramlásának megjelenítéséhez szükséges megfelelő támogatás nélkül. 2002-től az AspectJ IDE-bővítményeket adott ki az átfogó problémák megjelenítésének támogatására. Ezek a funkciók, valamint az aspektuskód-asszisztens és az újrafaktorálás ma már általánosnak számítanak.

Tekintettel az AOP erejére, ha egy progamozó logikai hibát követ el a keresztmetszet kifejezése során, az széleskörű programhibához vezethet. Ezzel szemben egy másik programozó megváltoztathatja a csatlakozási pontokat a programban – például metódusok átnevezésével vagy áthelyezésével – olyan módon, amelyre az aspektus író nem számított, és ez előre nem látható következményekkel járhat. A keresztmetszeti problémák modularizálásának egyik előnye, hogy egyetlen programozó is könnyen befolyásolhatja az egész rendszert; ennek eredményeként az ilyen problémák két vagy több fejlesztő közötti felelősségi konfliktusként jelennek meg egy adott hiba miatt. Ezeknek a problémáknak a megoldása azonban sokkal könnyebb lehet AOP jelenlétében, mivel csak egy aspektust kell megváltoztatni, míg az AOP nélküli problémák sokkal kiterjedtebbek.

Kritika[szerkesztés]

A legalapvetőbb kritika az AOP hatásával kapcsolatban az, hogy a vezérlési áramlás rejtett, és hogy nem csak rosszabb, mint a sokat szidott GOTO, de valójában szorosan hasonlít a viccként emlegetett COME FROM kijelentéssel/állítással. Az alkalmazás figyelmen kívül hagyása, ami az AOP számos definíciójában alapvető fontosságú (a kérdéses kódban nincs utalás arra, hogy tanácsot használnak, ami helyette a pointcut-ban van megadva), azt jelenti, hogy a tanács nem látható, ellentétben az explicit metódushívással.

Például, hasonlítsuk össze a COME FROM programot:

 5 INPUT X
10 PRINT 'Result is :'
15 PRINT X
20 COME FROM 10
25      X = X * X
30 RETURN

analóg szemantikával rendelkező AOP résszel:

main() {
    input x
    print(result(x))
}
input result(int x) { return x }
around(int x): call(result(int)) && args(x) {
    int temp = proceed(x)
    return temp * temp
}

Valójában a pontvágás függhet a futásidejű feltételektől, és így nem statikusan determinisztikus. Ez enyhíthető, de nem oldható meg statikus elemzéssel és IDE támogatással – amely megmutatja, hogy mely tanácsok egyeznek.

Az általános kritikák szerint az AOP „mind a modularitást, mind a kódszerkezetet javítani kívánja”, de egyesek szerint ez ellenkezik azzal, hogy ehelyett aláássa ezeket a célokat, és gátolja a „programok független fejlesztését és érthetőségét”. Pontosabban, a pontvágásokkal történő számszerűsítés megtöri a modularitást: „Általában az egész programra vonatkozó ismeretekkel kell rendelkezni ahhoz, hogy egy aspektus-orientált program dinamikus végrehajtásáról okoskodhassunk.” Továbbá, noha a céljai (modularizáló átfogó problémák) jól ismertek, a tényleges meghatározása nem világos, és nem különbözik egyértelműen más jól bevált technikáktól. Az átfogó problémák potenciálisan keresztezhetik egymást, és valamilyen megoldási mechanizmust, például rendelést igényelnek. Valójában az aspektusok vonatkozhatnak önmagukra is, ami olyan problémákhoz vezethet, mint a hazug paradoxon.

A technikai kritikák között szerepel, hogy a pontvágások számszerűsítése (meghatározza, hogy a tanácsokat hol hajtják végre) „rendkívül érzékeny a program változásaira”, amit a törékeny pontvágó problémaként ismernek. A pontvágokkal kapcsolatos problémák megoldhatatlannak tűnnek: ha a pontkivágások számszerűsítését explicit megjegyzésekre cseréljük, akkor helyette attribútum-orientált programozást kapunk, amely egyszerűen egy explicit szubrutinhívás, és ugyanazt a szórási problémát szenvedi el, mint amilyen az AOP megoldása volt.

Implementációk[szerkesztés]

A következő programozási nyelvek valósították meg az AOP-t a nyelven belül vagy külső könyvtárként:

Lásd még[szerkesztés]

További irodalom[szerkesztés]

Külső linkek[szerkesztés]

Jegyzetek[szerkesztés]

  1. "Adaptive Object Oriented Programming: The Demeter Approach with Propagation Patterns" Karl Liebherr 1996 ISBN 0-534-94602-X presents a well-worked version of essentially the same thing (Lieberherr subsequently recognized this and reframed his approach).
  2. Don Box. Essential.NET: The common language runtime. Addison-Wesley Professional, 206. o. (2002. november 4.). ISBN 978-0-201-73411-9. Hozzáférés ideje: 2011. október 4. 
  3. Roman, Ed. Mastering Enterprise JavaBeans. John Wiley and Sons, 285. o. (2005. január 1.). ISBN 978-0-7645-8492-3. Hozzáférés ideje: 2011. október 4. 
  4. Note: The examples in this article appear in a syntax that resembles that of the Java language.
  5. Archived copy. [2005. október 8-i dátummal az eredetiből archiválva]. (Hozzáférés: 2005. június 19.)
  6. Numerous: Afterthought Archiválva 2016. március 15-i dátummal a Wayback Machine-ben., LOOM.NET Archiválva 2008. augusztus 27-i dátummal a Wayback Machine-ben., Enterprise Library 3.0 Policy Injection Application Block Archiválva 2007. január 19-i dátummal a Wayback Machine-ben., AspectDNG Archiválva 2004. szeptember 29-i dátummal a Wayback Machine-ben., DynamicProxy Archiválva 2015. december 5-i dátummal a Wayback Machine-ben., Compose* Archiválva 2005. augusztus 21-i dátummal at Wikiwix, PostSharp Archiválva 2016. május 3-i dátummal a Wayback Machine-ben., Seasar.NET Archiválva 2006. július 25-i dátummal a Wayback Machine-ben., DotSpect (.SPECT) Archiválva 2006. március 31-i dátummal a Wayback Machine-ben., Spring.NET Archiválva 2006. április 2-i dátummal a Wayback Machine-ben. (as part of its functionality), Wicca and Phx.Morph Archiválva 2006. december 7-i dátummal a Wayback Machine-ben., SetPoint Archiválva 2008. október 7-i dátummal a Wayback Machine-ben.
  7. Welcome to as3-commons-bytecode. as3commons.org. [2014. október 3-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  8. Ada2012 Rationale. adacore.com. [2016. április 18-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  9. Function Hooks. autohotkey.com. [2013. január 17-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  10. Cobble. vub.ac.be. (Hozzáférés: 2018. május 5.)[halott link]
  11. AspectCocoa. neu.edu. [2007. október 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  12. ColdSpring Framework: Welcome, 2005. november 5. [2005. november 5-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  13. Closer Project: AspectL.. [2011. február 23-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  14. infra - Frameworks Integrados para Delphi - Google Project Hosting. [2015. szeptember 9-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  15. meaop - MeSDK: MeObjects, MeRTTI, MeAOP - Delphi AOP(Aspect Oriented Programming), MeRemote, MeService... - Google Project Hosting. [2015. szeptember 10-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  16. Google Project Hosting. [2014. december 25-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  17. RemObjects Cirrus. codegear.com. [2012. január 23-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  18. Emacs Advice Functions. gnu.org. [2011. október 24-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  19. AspectLua. [2015. július 17-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  20. MAKAO, re(verse)-engineering build systems. [2012. július 24-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  21. McLab. [2015. szeptember 24-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  22. AspectML - Aspect-oriented Functional Programming Language Research. [2010. december 5-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  23. Adam Kennedy: Aspect - Aspect-Oriented Programming (AOP) for Perl - metacpan.org. [2013. augusztus 31-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  24. Several: PHP-AOP (AOP.io) Archiválva 2014. augusztus 18-i dátummal at Wikiwix, Go! AOP framework Archiválva 2013. március 1-ji dátummal a Wayback Machine-ben., PHPaspect Archiválva 2016. augusztus 22-i dátummal a Wayback Machine-ben., Seasar.PHP Archiválva 2005. december 26-i dátummal a Wayback Machine-ben., PHP-AOP, Flow Archiválva 2018. január 4-i dátummal a Wayback Machine-ben., AOP PECL Extension Archiválva 2017. április 11-i dátummal a Wayback Machine-ben.
  25. bigzaphod.org is coming soon. www.bigzaphod.org. [2016. április 20-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  26. Several: PEAK Archiválva 2005. április 9-i dátummal a Wayback Machine-ben., Aspyct AOP, Lightweight Python AOP Archiválva 2004. október 9-i dátummal a Wayback Machine-ben., Logilab's aspect module Archiválva 2005. március 9-i dátummal a Wayback Machine-ben., Pythius Archiválva 2005. április 8-i dátummal a Wayback Machine-ben., Spring Python's AOP module Archiválva 2016. március 4-i dátummal a Wayback Machine-ben., Pytilities' AOP module Archiválva 2011. augusztus 25-i dátummal a Wayback Machine-ben., aspectlib Archiválva 2014. november 5-i dátummal a Wayback Machine-ben.
  27. PLaneT Package Repository : PLaneT > dutchyn > aspectscheme.plt. [2015. szeptember 5-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  28. AspectR - Simple aspect-oriented programming in Ruby. [2015. augusztus 12-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  29. Dean Wampler: Home. [2007. október 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  30. gcao/aspector. GitHub. [2015. január 4-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  31. AspectS. tu-ilmenau.de. [2006. január 6-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  32. MetaclassTalk: Reflection and Meta-Programming in Smalltalk. [2015. július 29-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  33. WEAVR. iit.edu. [2008. december 12-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  34. aspectxml - An Aspect-Oriented XML Weaving Engine (AXLE) - Google Project Hosting. [2015. szeptember 12-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)