Ugrás a tartalomhoz

Aspektusorientált programozás

Ellenőrzött
A Wikipédiából, a szabad enciklopédiából
(Aspektus-orientált programozás szócikkből átirányítva)

A számítástechnikában az aspektusorientált programozás (AOP) egy olyan programozási paradigma, amelynek célja a modularitás növelése azáltal, hogy lehetővé teszi a kereszthivatkozások szeparálását (SoC). Ez úgy történik, hogy kiegészítő viselkedést ad a meglévő kódhoz (advice), önmagában a kód módosítása nélkül, ehelyett külön megjelöli, hogy melyik kódot módosítják 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é teszi az üzleti logika szempontjából a nem központi viselkedés (például naplózás) hozzáadását a programhoz a funkcionalitás alapját képező kód túlzsúfolása nélkül. Az AOP alapja az aspektusorientált szoftverfejlesztésnek.

Az AOP programozási módszereket és eszközöket tartalmaz, amelyek támogatják a vonatkozások modulációját a forráskód szintjén, míg az "aspektusorientált szoftverfejlesztés" egy teljes mérnöki tudományágat jelent.

Az aspektusorientált programozás magában foglalja a program logikájának különálló részekre bontását (úgynevezett vonatkozások, koherens funkcionális területek). Szinte az összes programozási paradigma támogatja a vonatkozások bizonyos szintű csoportosítását és beágyazását különálló, független entitásokba absztrakciók (például függvények, eljárások, modulok, osztályok, metódusok) biztosításával, amelyek felhasználhatók ezeknek a vonatkozásoknak az implementálására, absztrakciójára és összeállítására. Néhány vonatkozás „átvág” számos absztrakción egy programon belül, és meghiúsítja a végrehajtás ezen formáit. Ezeket a vonatkozásokat cross-cutting (keresztülvágó) vagy horizontális vonatkozásoknak (vagy szimplán kereszthivatkozás) nevezik.

A naplózás egy kereszthivatkozási problémát szemléltet, mivel a naplózási stratégia szükségszerűen érinti a rendszer minden naplózott részét. A naplózás ezzel keresztezi az összes naplózott osztályt és metódust.

Minden AOP implementációnak vannak olyan átfogó kifejezései, amelyek mindegyik vonatkozást egységbe zárják. Az implementációk közötti különbség a biztosított konstrukciók erejében, biztonságában és használhatóságában rejlik. Például az olyan megszakítók, amelyek meghatározzák a keresztmetszet korlátozott formájának kifejezésére szolgáló metódusokat, a típusbiztonság vagy a hibakeresés támogatása nélkül. Az AspectJ-nek számos ilyen kifejezése van, melyeket beilleszthet egy speciális osztályba, egy aspektusba. Például egy aspektus megváltoztathatja az alapkód viselkedését (a program nem aspektusú részét), ha tanácsot (kiegészítő viselkedést) alkalmaz a különféle csatlakozási pontokban (a program pontjai), amelyeket egy mennyiségi meghatározás, vagy lekérdezés határoz meg, melyet pointcutnak nevezünk (amely észleli, hogy egy adott csatlakozási pont megegyezik-e). Egy aspektus binárisan kompatibilis szerkezeti változtatásokat is végrehajthat más osztályokban, például tagok vagy szülők hozzáadásával.

Története

[szerkesztés]

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

Gregor Kiczales és a Xerox PARC kollégái kifejlesztették az AOP kifejezett fogalmát, majd ezt követték az AspectJ AOP Java kiterjesztésével. Az IBM kutatócsoportja egy eszközi megközelítést alkalmazott a nyelvi tervezési megközelítés felett, és 2001-ben javaslatot tett a Hyper/J és a Concern Manipulation Environment környezetre, amelyek még nem voltak széles körben elterjedtek.

A cikk példái az AspectJ-t használják.

A Microsoft Transaction Server kiszolgálót tekintik az AOP első nagyobb alkalmazásának, amelyet az Enterprise JavaBeans követett.[2][3]

Motiváció és alapkoncepciók

[szerkesztés]

Általában egy aspektus szét van szórva vagy összekeveredve, ami megnehezíti a kód kezelhetőségét és megértését. Ez abban valósul meg, hogy egy függvényt (például naplózás), több független függvény használhat, teljesen független rendszerekben, különböző forrásnyelvekben. 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. Ezek a szempontok nem csak azon a rendszereknek a fő funkciójában keveredhetnek össze, amelyekben kifejeződnek, hanem akár egymással is. Ezért, az egyik kereszthivatkozás megváltoztatása hatással lehet a többi funkcióra.

Például, vegyünk egy banki alkalmazást, egy nagyon egyszerű koncepcióval, ami az egyik számláról a másikra utal összeget:[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 hagyja azokat a bizonyos szempontokat, amelyeket egy telepített alkalmazás igényelne: hiányzik a biztonsági ellenőrzés, annak ellenőrzésére, hogy a jelenlegi felhasználó rendelkezik-e engedéllyel e művelet végrehajtásához; egy adatbázis-tranzakciónak be kell építenie a műveletet a véletlen adatvesztés elkerülése érdekében; a diagnosztika érdekében a műveletet be kell jegyezni a rendszernaplóba. A példa kedvéért egy verzió, amely ezeket az új vonatkozásokat implementálja í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 egyéb érdekek keveredtek össze az alapvető funkcionalitással (néha üzleti logikai vonatkozásnak nevezik). A tranzakciók, a biztonság és a naplózás mind a kereszthivatkozásokat szemléltetik.

Most fontoljuk meg, mi történik, ha hirtelen meg kell változtatnunk (például) az alkalmazás biztonsági szempontjait. A program aktuális verziójában a biztonsággal kapcsolatos műveletek több metóduson keresztül lettek létrehozva, egy ilyen változtatás komoly erőfeszítéseket igényelne.

Az AOP megpróbálja ezt a problémát megoldani azáltal, hogy lehetővé teszi a programozónak, hogy kifejezze ezeket a kereszthivatkozásokat önálló modulokban, úgynevezett aspektusokban (szempontokban). A szempontok tartalmazhatnak adviceokat (a program meghatározott pontjaihoz csatolt kódot) és típusközi deklarációkat (strukturális tagok hozzáadva más osztályokhoz). A biztonsági modul például tartalmazhat olyan adviceokat, amelyek biztonsági ellenőrzést hajtanak végre a bankszámla elérése előtt. A pointcut meghatározza azokat az időpontokat (csatlakozási pontok), amikor egy bankszámlához hozzáférhetünk, és az advice törzsében szereplő kód határozza meg a biztonsági ellenőrzés végrehajtásának implementációját. Így mind az ellenőrzés, mind a területek egy részen kezelhetők. Ezenkívül egy jó pointcut előrejelzi a program későbbi változásait, tehát ha egy másik fejlesztő új metódust hoz létre a bankszámla eléréséhez, az advice az új módszerre vonatkozik annak végrehajtásakor.

A fentebb említettek példájára egy naplózás megvalósítása egy aspektusban: 

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

Az AOP kapcsán gondolhatunk egy hibakeresési eszközre, vagy akár egy felhasználói szintű kellékre. Az advicet tartalékolhatjuk azokra az esetekre, amikor nem sikerül egy funkciót megváltoztatni (felhasználói szint),[5] vagy pedig nem akarjuk megváltoztatni a függvényt az élesen futó alkalmazásban (hibakezelés)

Csatlakozási pontok modellje

[szerkesztés]

Az aspektusorientált nyelv tanáccsal kapcsolatos komponense meghatározza a csatlakozási pontot (JPM). A JPM három dolgot határoz meg:

  1. Mikor futhat az advice? Ezeket csatlakozási pontoknak nevezzük, mivel ezek egy futó program pontjai, ahol további viselkedés hasznos módon csatlakoztatható. A csatlakozási pontnak címezhetőnek és érthetőnek kell lennie egy átlagos programozó számára, hogy hasznos legyen. Valamint stabilnak kell, hogy maradjon a lényegtelen programváltozások között is, hogy egy aspektus is szintén stabil maradjon ilyen változások hatására. Számos AOP implementáció támogatja a metódus végrehajtását és a mező hivatkozásokat, referenciákat csatlakozási pontként.
  2. A csatlakozási pontok (pointcuts) meghatározásának (vagy számszerűsítésének) módja. A pointcut meghatározza, hogy egy adott csatlakozási pont megegyezik-e. A leghasznosabb pointcut nyelvek olyan szintaxist alkalmaznak, mint az alapnyelv ( például az AspectJ Java aláírásokat használ) és lehetővé teszik az újbóli felhasználást az elnevezés és a kombináció révén.
  3. A csatlakozási ponton futó kód megadásának eszköze. Az AspectJ meghívja ezt az advicet és futtathatja azt a csatlakozási pontok előtt, után és körül. Egyes implementációk támogatják egy metódus definiálását egy másik osztályban lévő aspektuson belül.

A csatlakozási pont modellek összehasonlíthatók meghatározásaik, valamint ezekben a pontokban engedélyezett műveleteik és a kifejezhető szerkezeti fejlesztéseik, és a kitett csatlakozási pontjaik alapján.

Az AspectJ csatlakozási pont modellje

[szerkesztés]
  • Az AspectJ csatlakozási pontjai magukban foglalják a metódus vagy a konstruktor hívását, végrehajtását, az osztály vagy objektum inicializálását, a mező olvasási és írási hozzáférését, a kivételkezelőket stb. Nem tartalmaznak ciklusokat, ős (super) hívásokat, dobás (throw) kikötéseket, valamint több utasítást sem, stb.
  • A mutatókat primitív pointcut jelölők (PCD) kombinációi határozzák meg.

    A „kinded” PCD-k megfelelnek egyfajta csatlakozási pontnak (például metódus végrehajtás), és hajlamosak Java szignatúrák bevitelére. Az egyik ilyen pointcut így néz ki: 

     execution(* set*(*))

    Ez megegyezik a metódus végrehajtási csatlakozási ponttal, ha a metódus neve „ "set" -tel kezdődik, és pontosan egy argumentumot vár.

    A „dynamic” (dinamikus) PCD-k ellenőrzik a futásidejű típusokat és kötött változókat. Például: 

      this(Point)

    Ez a pointcut akkor egyezik meg, ha az éppen végrehajtó objektum a Point osztály példánya. Vegyük figyelembe, hogy az osztály meg nem határozott neve felhasználható a Java normál típusú keresésén keresztül.

    A „terület” (scope) PCD-k korlátozzák a csatlakozási pont lexikai hatókörét. Például: 

     within(com.company.*)

    Ez a pointcut megegyezik a com.company csomag bármely típusú csatlakozási pontjával. A * a helyettesítő karakterek egyik formája, amely felhasználható ahhoz, hogy több dolgot egy aláírással egyeztessen.

    A mutatók összeállíthatók és megnevezhetők újrafelhasználás céljából. Például: 

     pointcut set() : execution(* set*(*) ) && this(Point) && within(com.company.*);
    Ez a pointcut megegyezik a metódus végrehajtás csatlakozási pontjával, ha a metódus neve "set" -tel kezdődik, és ez a Point típusú objektum példánya a com.company csomagban. Erre utal a "set()" név használata.
  • Az advice azt határozza meg, hogy egy csatlakozási ponton (előtte, utána vagy körülötte) futtasson-e (pointcuttal megadva) egy bizonyos kódot (mint például egy metóduson belül lévő kód). Az AOP futásiideje automatikusan meghívja az advicet, ha a pointcut megegyezik a csatlakozási ponttal. Például: after() : set() { Display.update(); } Ez ténylegesen meghatározza: „Ha a set() pointcut megegyezik a csatlakozási ponttal, akkor futtassa a Display.update() kódot, miután a csatlakozási pont befejeződött”.

Egyéb potenciális csatlakozási pont modellek

[szerkesztés]

Más típusú JPM is létezik. Az összes advice nyelv meghatározható a JPM alapján. Például az UML feltételezett nyelvén a következő JPM lehet:

  • A csatlakozási pontok mind a modell elemei.
  • A pointcutok olyan logikai kifejezésekre vonatkoznak, amelyek a modell elemeit egyesítik.
  • A befolyásolás eszköze ezeken a pontokon az összes illeszkedő csatlakozási pont megjelenítése.

Típusközi deklarációk

[szerkesztés]

A típusközi deklarációk lehetőséget adnak a modulok felépítését érintő kereszthivatkozások kifejezésére. Ezek más néven nyílt osztályok és kiterjesztési metódusok, amelyek lehetővé teszik a programozók számára, hogy egy helyen deklarálják egy másik osztály tagjait vagy szüleit, általában azért, hogy egy problémára vonatkozó kód egészét egy aspektusben összevonják. Például, ha egy programozó a visitor felhasználásával valósította meg a megjelenítés-frissítést, egy visitor (látogató) mintát használó típusú típusközi deklaráció az AspectJ-ben így nézhet ki: 

  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.

Fontos 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 megvalósítás azt várja el, hogy minden klienst folyamatosan ellenőrízzen.

Implementáció

[szerkesztés]

Az AOP programok kétféleképpen befolyásolhatják a többi programot, az alapul szolgáló nyelvektől és a környezettől függően:

  1. Egy kombinált program készül, amely eredeti nyelven érvényes és megkülönbözhetetlen a hétköznapi programtól a végső interpreterig (fordító).
  2. A végső fordító vagy a környezet frissül az AOP funkciók megértéséhez és megvalósításához.

A környezetek 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 „szövésnek” (weaving) nevezett folyamat révén – a program átalakításának különös esete. Egy aspektus szövő leolvassa az aspektusorientált kódot, és megfelelő objektumorientált kódot generál integrált szempontokkal belőle. Ugyanaz az AOP nyelv különféle szövésmódszerekkel implementálható, így a nyelv szemantikája soha meg nem érthető a szövés implementálásának szempontjából. Csak a megvalósítás sebességét és a telepítés könnyebbségét befolyásolja az, hogy milyen kombinációs módszert alkalmaznak.

A rendszerek forrásszintű szövést hajtanak végre olyan előprocesszorok segítségével (mivel a C++ eredetileg a CFront programban került megvalósításra), amelyek megkövetelik a hozzáférést a program forrásfájljaihoz. A Java jól definiált bináris formája azonban lehetővé teszi a bytekód szövők számára, hogy bármilyen Java programmal együtt működjenek .class fájl formátumban. A bytekód szövők telepíthetők (deploy) az építés (build) során, vagy ha a szövési modell osztályonkénti, akkor az osztálybetöltés során. Az AspectJ 2001-ben forrásszintű szövést kezdett kialakítani, majd 2002-ben egy osztályonkénti bytekód szövőt hozott létre, és fejlett terhelési idő támogatást nyújtott az AspectWerkz 2005-ös integrációja után.

Bármely megoldásnak, amely egyesíti a programokat futásidő alatt, olyan aspektusokat kell tartalmaznia, amelyek megfelelően elkülönítik őket, hogy fenntartsák a programozó szegregált modelljét. A Java bytekód támogatása több forrásfájlnál lehetővé teszi a hibakeresők számára, hogy egy megfelelően szőtt .class fájlon átlépjenek a forrásszerkesztőben. Néhány harmadik féltől származó kódvisszafejtő program (decompiler) nem tudja feldolgozni a szőtt kódot, mert Javac által előállított kódot várnak, az összes támogatott bytekód forma helyett.

Az üzembe helyezési időszövés (deploy-time weaving) egy másik megközelítést kínál.[6] Ez alapvetően utófeldolgozást von maga után, de a létrehozott kód javítása helyett ez a szövés megközelítés alosztályozza a meglévő osztályokat úgy, hogy a módosításokat metódus felülírással (method overriding) vezeti be. A meglévő osztályok változatlanok maradnak, még futásidejűleg is, és az összes létező eszköz (hibakeresők, profilkészítők stb.) felhasználható a fejlesztés során. Hasonló megközelítés már bebizonyosodott számos Java EE alkalmazáskiszolgáló – például az IBM WebSphere – implementálásában.

Terminológia

[szerkesztés]

Az aspektusorientált programozásban használt alap terminológia a következőket foglalja magában:

Kereszthivatkozás (Cross-cutting concern)
Annak ellenére, hogy az OO modell legtöbb osztálya egyetlen, specifikus funkciót fog ellátni, gyakran közös, másodlagos követelményeket osztanak meg más osztályok felé. Előfordulhat például, hogy naplózást szeretnénk hozzáadni az adat-hozzáférési réteg osztályaihoz és a UI réteg osztályaihoz is, amikor egy szál belép vagy kilép egy metódusból. További aggályok kapcsolódhatnak a biztonsághoz például hozzáférési jogosultságok vezérlés,[7] vagy az információáramlás-vezérlés.[8] Annak ellenére, hogy az osztályok nagyon eltérő elsődleges funkcióval rendelkeznek, a másodlagos funkciók végrehajtásához szükséges kód gyakran azonos.
Advice
Ez a kiegészítő kód, amelyet alkalmazni szeretnénk a meglévő modellre. Példánkban ez az a naplózási kód, amelyet alkalmazni akarunk, amikor a szál belép a metódusba, vagy kilép a metódusból.
Pointcut
Ez a kifejezés az alkalmazás azon végrehajtási pontjához adódik, amelyen kereszthivatkozást alkalmazunk. Példánkban egy pointcutot érünk el, amikor a szál belép a metódusba, és szintén egy pointcutot érünk el akkor, amikor a szál kilép a metódusból.
Aspektus
A pointcut és az advice kombinációját aspektusnak nevezzük. A fenti példában hozzáadunk egy naplózási aspektust alkalmazásunkhoz, egy pointcut definiálásával, és egy helyes advice-val.

Összehasonlítás más programozási paradigmákkal

[szerkesztés]

A aspektusok az objektumorientált programozás és a számítási reflexiók során merültek fel. Az AOP nyelvek funkciója hasonló, de korlátozóbb, mint a metaobjektum protokollok. Az aspektusok szorosan kapcsolódnak a programozási koncepciókhoz, például az objektumokhoz, a mixinekhez és a delegáláshoz (delegation). Az aspektusorientált programozási paradigmák felhasználásának további módjai a Kompozíciószűrő és a hyperslice megközelítés. Már az 1970-es évek óta a fejlesztők olyan lehallgatási és küldési javításokat használnak, amelyek hasonlítanak az AOP megvalósítás metódusaira, ám ezeknek a szemantikáknak soha nem volt olyan része, amelyeket a keresztmetszeti (crosscutting) leírások biztosítanak.

A tervezők fontolóra vették a kód szeparálásának alternatív lehetőségeit, például a C# részleges típusait, de az ilyen megközelítésekben nincs olyan számszerűsítő mechanizmus, amely lehetővé teszi a kód több csatlakozási pontjának elérését egyetlen deklaratív kijelentéssel (statement).

Bár úgy tűnhet, hogy független, a tesztelés során a mock vagy metódus részlet (method stub) használata AOP technikák alkalmazását igényli, például az advice környékén és így tovább. Az együttmûködõ objektumok itt a teszt céljából  kereszthivatkozássá válnak. Így a különféle mock objektum keretrendszerek biztosítják ezeket a funkciókat. Például egy folyamat meghív egy szolgáltatást, hogy megkapja az egyenlegösszeget. A folyamat tesztelésekor, az összeg származása, nem fontos, csak az, hogy a folyamat a követelményeknek megfelelően használja az egyenleget.

Az örökléssel kapcsolatos kérdések

[szerkesztés]

A programozóknak el kell tudniuk olvasni a kódot, és meg kell érteniük, hogy mi történik a hibák elkerülése érdekében.[9] Még megfelelő oktatás mellett is nehézkes lehet a kereszthivatkozások megértése a program statikus felépítésének és dinamikus folyamatának vizualizálásával kapcsoltban nyújtott megfelelő támogatás nélkül.[10] 2002-től kezdve az AspectJ IDE-bővítményeket kezdett biztosítani a kereszthivatkozások vizualizálásának támogatására. Ezek a szolgáltatások, valamint az aspektus kód segéd és a refaktorálás manapság elterjedtek.

Tekintettel az AOP erejére, ha egy programozó logikai hibát követ el a kereszthivatkozás kifejezésében, az széles körű programhibához vezethet. Ezzel szemben egy másik programozó megváltoztathatja a program csatlakozási pontjait – például átnevezéssel vagy metódusok áthelyezésével – oly módon, amit az aspektus író nem várt előre. A kereszthivatkozás modularizálásának egyik előnye, hogy lehetővé teszi egy programozó számára azt, hogy könnyen befolyásolja az egész rendszert; Ennek eredményeként az ilyen problémák konfliktusként jelennek meg két vagy több fejlesztő közötti felelősségként egy adott hiba miatt. E problémák megoldása azonban sokkal könnyebb lehet AOP jelenlétében, mivel csak az aspektust kell megváltoztatni, míg a problémák AOP nélkül sokkal elterjedőbbek lehetnek a programon belül.

Kritika

[szerkesztés]

Az AOP hatásának legalapvetőbb kritikája az, hogy az irányítás áramlás (control flow) el van takarva, és hogy ez nem csak rosszabb, mint a sok rosszindulatú GOTO, hanem valójában szorosan analóg a COME FROM kijelentés viccével.[10] Az alkalmazás elhanyagoltsága, amely alapvető fontosságú az AOP sok meghatározása szempontjából (a kérdéses kódnak nincs utalása arra, hogy egy advicet alkalmazni fognak, ehelyett a pointcutban pontosítanak), azt jelenti, hogy az advice nem látható, ellentétben egy explicit metódus hívással.[10][11] Például hasonlítsa össze a COME FROM programot:[10] 

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

Analóg szemantikai AOP töredékkel (fragment): 

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 pointcut függhet a futásidejű körülményektől, és így nem lehet statikusan determinisztikus. Ezt enyhíteni lehet, de nem lehet megoldani statikus elemzéssel és IDE támogatással, amely megmutatja, hogy mely tanácsok egyeznek meg potenciálisan.

Általános kritika az, hogy az AOP célja "mind a modularitás, mind a kód szerkezetének" javítása, ám néhányan azt állítják, hogy ehelyett aláássák ezeket a célokat, és akadályozzák a "programok független fejlesztését és érthetőségét".[12] Pontosabban, a pointcut általi számszerűsítés megszakítja a modularitást: "általában egy teljes program ismeretével kell rendelkezni egy aspektus orientált program dinamikus végrehajtásának megvitatására."[13] Továbbá, bár céljait (a kereszthivatkozások modularizálását) jól értik, a tényleges definíciója nem egyértelmű, és nem különböztethető  meg egyértelműen a többi jól bevált technikától.[12] A kereszthivatkozások potenciálisan keresztül vágják egymást, és valamilyen felbontási mechanizmust igényelnek, mint például az elrendezés.[12] Valójában az aspektusok magukra is alkalmazhatók, és olyan problémákhoz vezethetnek, mint például a hazug paradoxona.[14]

A technikai kritika magában foglalja azt, hogy a pointcutok mennyiségi meghatározása (amely meghatározza az adviceok végrehajtásának helyét) "rendkívül érzékeny a program változásaira", amelyet törékeny pointcut problémaként ismernek.[12] A pointcuttal kapcsolatos problémák megoldhatatlanok: ha a pointcutok számszerűsítését explicit kommentárokkal helyettesítjük, akkor inkább egy attribútumorientált programozást kapunk, amely egyszerűen egy explicit szubrutin hívás, és ugyanolyan szétszórási problémától szenved, amely megoldására az AOP-t tervezték.[12]

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.

További linkek

[szerkesztés]

Megjegyzések és hivatkozások

[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. ↑ gnu.org. www.gnu.org . [2017. december 24-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  6. ↑ Archived copy. [2005. október 8-i dátummal az eredetiből archiválva]. (Hozzáférés: 2005. június 19.)
  7. ↑ B. De Win, B. Vanhaute and B. De Decker. "Security through aspect-oriented programming". In Advances in Network and Distributed Systems Security (2002).
  8. ↑ T. Pasquier, J. Bacon and B. Shand. "FlowR: Aspect Oriented Programming for Information Flow Control in Ruby". In ACM Proceedings of the 13th international conference on Modularity (Aspect Oriented Software Development) (2014).
  9. ↑ Edsger Dijkstra, Notes on Structured Programming Archiválva 2006. október 12-i dátummal a Wayback Machine-ben., pg. 1-2
  10. ↑ a b c d (2004. szeptember 1.) „AOP Considered Harmful”. European Interactive Workshop on Aspects in Software (EIWAS). [2016. március 23-i dátummal az eredetiből archiválva]. Hozzáférés: 2018. május 5. 
  11. ↑ C2:ComeFrom
  12. ↑ a b c d e Steimann (2006). „The paradoxical success of aspect-oriented programming”. ACM SIGPLAN Notices 41 (10), 481. o. DOI:10.1145/1167515.1167514.  , (slides Archiválva 2016. március 4-i dátummal a Wayback Machine-ben.,slides 2 Archiválva 2015. szeptember 23-i dátummal a Wayback Machine-ben., abstract Archiválva 2015. szeptember 24-i dátummal a Wayback Machine-ben.), Friedrich Steimann, Gary T. Leavens, OOPSLA 2006
  13. ↑ 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.
  14. ↑ a b 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.)
  15. ↑ 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.
  16. ↑ Ada2012 Rationale. adacore.com. [2016. április 18-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  17. ↑ Function Hooks. autohotkey.com. [2013. január 17-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  18. ↑ Cobble. vub.ac.be. (Hozzáférés: 2018. május 5.)[halott link]
  19. ↑ AspectCocoa. neu.edu. [2007. október 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  20. ↑ 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.)
  21. ↑ Closer Project: AspectL.. [2011. február 23-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  22. ↑ 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.)
  23. ↑ 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.)
  24. ↑ Google Project Hosting. [2014. december 25-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  25. ↑ RemObjects Cirrus. codegear.com. [2012. január 23-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  26. ↑ 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.)
  27. ↑ AspectLua. [2015. július 17-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  28. ↑ 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.)
  29. ↑ McLab. [2015. szeptember 24-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  30. ↑ 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.)
  31. ↑ 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.)
  32. ↑ 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.
  33. ↑ 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.)
  34. ↑ 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.
  35. ↑ 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.)
  36. ↑ 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.)
  37. ↑ Dean Wampler: Home. [2007. október 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  38. ↑ gcao/aspector. GitHub. [2015. január 4-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. augusztus 11.)
  39. ↑ AspectS. tu-ilmenau.de. [2006. január 6-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  40. ↑ 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.)
  41. ↑ WEAVR. iit.edu. [2008. december 12-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. május 5.)
  42. ↑ 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.)

További irodalom

[szerkesztés]

Fordítás

[szerkesztés]

Ez a szócikk részben vagy egészben az Aspect-oriented programming című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

Külső linkek

[szerkesztés]
A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Aspektusorientált_programozás&oldid=27273310”