Aspektus-orientált programozás (AOP)

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által, 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

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 .

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.

Motiváció és alapfogalmak

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:

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

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

• 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

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övetkező 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

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ó

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

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

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

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 programozó 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

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 pointcutban 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ágókkal 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

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:

• .NET Framework languages (C# / VB.NET)
  • PostSharp is a commercial AOP implementation with a free but limited edition.
  • Unity provides an API to facilitate proven practices in core areas of programming including data access, security, logging, exception handling and others.
• ActionScript
• Ada
• AutoHotkey
• C / C++
• COBOL
• The Cocoa Objective-C frameworks
• ColdFusion
• Common Lisp
• Delphi
• Delphi Prism
• e (IEEE 1647)
• Emacs Lisp
• Groovy
• Haskell
• Java
  • AspectJ
• JavaScript
• Logtalk
• Lua
• make
• Matlab
• ML
• Perl
• PHP
• Prolog
• Python
• Racket
• Ruby
• Squeak Smalltalk
• UML 2.0
• XML

Lásd még

• Distributed AOP
• Attribute grammar, a formalism that can be used for aspect-oriented programming on top of functional programming languages
• Programming paradigms
• Subject-oriented programming, an alternative to Aspect-oriented programming
• Role-oriented programming, an alternative to Aspect-oriented programming
• Predicate dispatch, an older alternative to Aspect-oriented programming
• Executable UML
• Decorator pattern
• Domain-driven design

További irodalom

• (1997) „Aspect-oriented programming”. ECOOP'97 1241: 220–242. doi:10.1007/BFb0053381.  The paper generally considered to be the authoritative reference for AOP.
• Andreas Holzinger. Applying Aspect Oriented Programming (AOP) in Usability Engineering processes: On the example of Tracking Usage Information for Remote Usability Testing., D. A. Marca, B. Shishkov and M. v. Sinderen (editors), 53–56. o. (2011) 
• Robert E. Filman. Aspect-Oriented Software Development (2004). ISBN 978-0-321-21976-3 
• Renaud Pawlak, Lionel Seinturier. Foundations of AOP for J2EE Development (2005). ISBN 978-1-59059-507-7 
• Laddad, Ramnivas. AspectJ in Action: Practical Aspect-Oriented Programming (2003). ISBN 978-1-930110-93-9 
• Jacobson, Ivar. Aspect-Oriented Software Development with Use Cases (2005). ISBN 978-0-321-26888-4 
• Aspect-oriented Software Development and PHP, Dmitry Sheiko, 2006
• Siobhán Clarke. Aspect-Oriented Analysis and Design: The Theme Approach (2005). ISBN 978-0-321-24674-5 
• Raghu Yedduladoddi. Aspect Oriented Software Development: An Approach to Composing UML Design Models (2009. április 26.). ISBN 978-3-639-12084-4 
• "Adaptive Object-Oriented Programming Using Graph-Based Customization" – Lieberherr, Silva-Lepe, et al. – 1994
• Zambrano Polo y La Borda (2013. június 5.). „Addressing aspect interactions in an industrial setting: experiences, problems and solutions”, 159. o. DOI:10.35537/10915/35861. (Hozzáférés: 2014. május 30.)  
• Wijesuriya, Viraj Brian (2016-08-30) Aspect Oriented Development, Lecture Notes, University of Colombo School of Computing, Sri Lanka
• Groves, Matthew D.. AOP in .NET (2013). ISBN 9781617291142 

Külső linkek

• Eric Bodden's list of AOP tools in .net framework
• Aspect-Oriented Software Development, annual conference on AOP
• AspectJ Programming Guide
• The AspectBench Compiler for AspectJ, another Java implementation
• Series of IBM developerWorks articles on AOP
• Laddad: I want my AOP!, Part 1. JavaWorld, 2002. január 18. (Hozzáférés: 2020. július 20.) A detailed series of articles on basics of aspect-oriented programming and AspectJ
• What is Aspect-Oriented Programming?, introduction with RemObjects Taco
• Constraint-Specification Aspect Weaver
• Aspect- vs. Object-Oriented Programming: Which Technique, When? Archiválva 2021. április 15-i dátummal a Wayback Machine-ben
• Gregor Kiczales, Professor of Computer Science, explaining AOP, video 57 min.
• Aspect Oriented Programming in COBOL Archiválva 2008. december 17-i dátummal a Wayback Machine-ben.
• Aspect-Oriented Programming in Java with Spring Framework
• Wiki dedicated to AOP methods on.NET
• Early Aspects for Business Process Modeling (An Aspect Oriented Language for BPMN)
• Spring AOP and AspectJ Introduction
• AOSD Graduate Course at Bilkent University
• Introduction to AOP – Software Engineering Radio Podcast Episode 106
• An Objective-C implementation of AOP by Szilveszter Molnar
• Aspect-Oriented programming for iOS and OS X by Manuel Gebele
• DevExpress MVVM Framework. Introduction to POCO ViewModels