Aspect-orientált programozás (aoop), amelyhez jobb használni
Ez a kérdés arra késztetett, hogy gondolkodjam el az AOP használatának hatékony módjait egyes olyan szoftverrendszerekben, amelyekkel dolgoztam. Rájöttem, hogy el kell gondolkodnod, hogyan és mikor kezdjen új módszereket alkalmazni, különösen, ha új gondolkodási módokra van szükség. Az AOP, amely korábban említett ebben a cikkben, csak új megközelítést jelent. Szeretnék egy kicsit beszélni a módszerekről, amelyek véleményem szerint az AOP-t használják. Emellett megvizsgáljuk az AOP néhány legfrissebb eredményét is, amelyek megkönnyíthetik a megértését.
Például a szempont-orientált Java nyelvet fogják használni. Jelenleg több olyan programozási nyelv is létezik, amelyek aspektus-orientált megvalósítással rendelkeznek. Ezek közé tartozik az AspectC ++ és még az AspectL is, azaz a Lisp aspektus-orientált megvalósítása. 1
AOP koncepciók áttekintése
Ahhoz, hogy megértsük az AOP vitáját, több fogalmat is meg kell tudnunk. Az alapkoncepció a csatlakozási pont. Ez a koncepció, amelyet minden programozó ismer, és amelynek nincs neve. Egy csatlakozási pont egy "pontosan meghatározott pont a program végrehajtásának folyamatában". 3 Számos csatlakozási pont létezik, például egy hívás vagy visszaváltási módszer, amely normális visszatérés vagy kivétel létrehozása lehet.
Az AOP-ban meg kell találnia a módot a program csatlakozási pontjainak azonosításához. Az AspectJ-ban pontpontot használunk egy vagy több csatlakozási pont leírására. A pontcut olyan kifejezés, amely leír egy kapcsolati pontot. A pontpontot kérésnek lehet tekinteni a kóddal, amely visszaküldi a kapcsolódási pontok halmazát.
Ha kiválaszt egy kapcsolati pontot, tanácsos mechanizmust biztosítunk számukra. Az Útmutató egy végrehajtható kód, amelyet akkor futtatnak, amikor a kapcsolódási pontot a program végrehajtásakor érjük el. A kapcsolódási pontok, pontmutatók és tanácsok a szoftver dinamikus tulajdonságainak megvalósítására szolgálnak. A tanácsmechanizmus megváltoztatja a program végrehajtható kódjának jellemzőit.
Példák az AOP-re
Most vegye figyelembe azokat a példákat, ahol az AOP-ot használhatja, és ahol használják. Néhány példa a termelési rendszerektől származik, mások a működési és fejlesztési folyamatból származnak. Kezdjük a fejlesztők néhány példájával.
Végrehajtási nyom
Elképesztő, hogy hány fejlesztő beírja a nyomtatott nyilatkozatok fajtáit a kódba a hibakereséshez vagy a program végrehajtásának nyomon követéséhez. A hibakeresõk esetében ez az információ érvényes. De ez a vita nem kapcsolódik hibakeresők tanulmányozásához. Természetesen vannak erős érvek a program szövegének nyomon követésére. Az AspectJ fejlesztőeszközök (AJDT) jelenlegi példaképe az Eclipse-ben tökéletes példa egy olyan szempontra, amely végrehajtja a programok végrehajtási nyomát. A példát az Eclipse súgórendszer részletesen ismerteti. Az AspectJ programozási útmutatóban is megtalálható.
A példában van egy kis Java alkalmazás, amely kétdimenziós formákat, például köröket és négyzeteket ábrázoló osztályokból áll. Az alkalmazásnak van egy olyan eljárása is, amely két kört és négyzetet hoz létre, és megjeleníti tulajdonságait, például területeket, kerületeket és a központok közötti távolságot. A program indítása után a kimenetnek meg kell felelnie az 1. ábrának.
1. ábra: Formátumú programadatok
A módszeres hívások tényleges sorrendjét kétféleképpen tekintheti meg. Az első megközelítésben minden olyan módszer elejére beillesztheti a kódot, amely egy üzenetet ad ki a módszer és az osztály nevével, valamint a módszer hívásával. Ezt minden módszer esetében meg kell tenni. A második megközelítés egy olyan szempont létrehozása, amely ugyanazt a műveletet hajtja végre. Ebben a megközelítésben nem kell megváltoztatnia az alkalmazáskódot.
A nyomkövetési példa egy program több változatából áll, amelyek segítségével nyomon követheti a szempontokat. Tekintsük a legújabb verziót. Más verziókhoz lásd az AspectJ Programozási útmutatót.
A megbízható nyomkövetési mechanizmus megoldása két fájlból áll. Az első fájl absztrakt szempont. Ez a szempont hasonlít egy absztrakt osztályhoz, ahol néhány kódot hagynak a programozók számára egy származtatott osztályba való bevezetésre, vagy ebben az esetben egy származtatott szempontból. A Trace nevű absztrakt aspektusnak számos szabványos módszere van a metódus vagy a konstruktornak való bejövő és kilépő üzenetek kiadására, valamint a kimeneti adatok formázására. Ha a szempontokat nem használják, ezek a módszerek a segítő osztályban vannak, és nyomon követési információkat jelenítenek meg. A nyomkövetés lehetővé teszi a programozók számára a TRACELEVEL tulajdonság beállításának megadását is. Három szint van: nincsenek üzenetek, nem strukturált üzenetek, és a beágyazott hívások megjelenítésére strukturált üzenetek.
A nyomkövetés három pontot határoz meg: két betont és egy absztrakt (lásd a 2. ábrát). Bármely olyan aspektus, amely kiterjeszti a Trace aspektusát, absztrakt metszetnek kell lennie, myClass. A pontcut célja az, hogy kiválassza a javasolt kapcsolódási pontokat tartalmazó objektumok osztályait. Ez lehetővé teszi a fejlesztők számára, hogy eldöntsék, mely osztályok szerepeljenek a kimeneti nyomkövetési adatokban.
2. ábra: Nyomjelzés a nyomon követés szempontjából
A Pointcut myConstructor minden olyan konstruktor elején kiválasztja a kapcsolódási pontokat az osztályban lévő objektumhoz, amelyre a myClass van kiválasztva. A csomópont valójában a tervező teste. A myMethod hasonló a myConstructorhoz, de kiválasztja bármelyik módszer végrehajtását a kiválasztott osztályban. Vegye figyelembe, hogy a toString módszer végrehajtása kihagyásra kerül, mivel a tanácskódban használják.
A tanács kódexe nagyon egyszerű. Minden egyes csatlakozási pont elé beillesztett tanácskód, valamint a kapcsolódási pont után végrehajtott tanácsadás. Ez a 3. ábrán látható.
3. ábra. A nyomkövetés szempontjai
A Trace elem használatához kiterjeszti és pontosan végrehajtja az absztrakt mutatópontot. A 4. ábra a mintaprogram testét mutatja a TraceMyClasses szempont szerint. A Pontcut csak azokat a objektumokat választhatja ki, amelyek a TwoDShape, a Circle vagy a Square osztályok példái. A fő módszer a TRACELEVEL beállítást, a program végrehajtási nyomkövetőjét inicializálja, és elindítja a példa fő módját.
4. ábra: A nyomvonal egy bizonyos aspektusa
Az 5. ábra a példának néhány kimenetét mutatja. Vegye figyelembe, hogy az összes objektum információ megjelenik. Ez az egyes objektumok toString metódusának része. Pointcut (egy pontszelet) A myClasses egy tárgyat (tanácsot) hirdet, amely megkönnyíti az objektumra vonatkozó információk felvételét.
5. ábra Példa a kimeneti nyomkövetési adatokra
Milyen előnyökkel jár az AOP nyomon követése, ha a nyomkövetési kódot helyesen helyezi be? Számos előnye van.
- A nyomkövetési viszonyhoz társított összes forráskód egy helyen (két szempont) van tárolva;
- A nyomkövetési kód könnyen beszúrható és törölhető. Ehhez a szempontokat eltávolítják a szerkezet konfigurációjából;
- A nyomkövetési kód bármely helyhez hozzáadható, még akkor is, ha új módszereket adnak hozzá a célosztályokhoz. Ez lehetővé teszi a programozó hibáinak kiküszöbölését. Ha töröl egy szempontot a terv konfigurációjából, biztos lehet benne, hogy minden nyomkövetési kód törlődik, és semmi sem hiányzik;
- Újra felhasználható szempontot alkalmazunk és javíthatunk.
Szerződéses vagy biztonságos programozás
A széles körű könyvtárak létrehozásakor nem lehet biztos abban, hogy a módszerekhez adott argumentumok megbízhatósága meg van győződve. Az érveket meg kell vizsgálni, mielőtt azokat az egyes módszerek logikájával feldolgoznák. Ez egy példa a biztonságos programozásra. Feltételezzük, hogy minden lehetséges hibát kegyes módon kezelünk.
Hozzunk létre egy szempontot az összes érv ellenőrzéséhez az állami módszereknél. Először is létrehozunk egy pontot. Az előző példánál fogjuk használni a pointClut myClass-ot, és hozzáadunk egy pontcut az olyan konstruktorok kiválasztásához, amelyeknek meg kell vizsgálniuk az argumentumokat, valamint egy olyan távolságmérési módot, amelyet nem kell NULL értékkel hívni. A 6. ábra a szükséges pontcut készletét mutatja. Ne feledje, hogy a második pontvágás meghatározza a TwoDShape példány pontcut pontját. Ez azt jelenti, hogy ez a pontválasztás az objektumokon csak a távolságméréshez tartozó hívásokat választja ki.
6. ábra: Pointcut (szelet pontok) az argumentumok teszteléséhez
Végül hozzá kell adnia a vonatkozó tanácsokat (ajánlások). Az egyszerűség kedvéért mi származik egy üzenetet detektál érvénytelen argumentum, és aztán, ha theconstructor, változtassa meg a tényleges értékek nullára és figyelmen kívül hagyja a hívást távolság technika adáskor NULL értéket. A 7. ábra két ilyen tanácselemet mutat be.
7. ábra Az argumentumellenőrzés tanács eleme
Amikor megpróbálja végrehajtani a következő mondatot:
Kör c3 = új kör (3.0,2.0, -2.0);
a programban a következő üzenetet kapja:
A hibaüzenetekkel sokkal többet tehet, ha megadja a pontos sorszámot és a forrásfájl nevét, de ez a példa nem szolgál erre a célra.
Nagy projektekben, ahol sok osztály és számos interfész használatos, az argumentumellenőrzést végrehajtó szempontok kódja külön mappába rendezhető. Számos módot tudok biztosítani az egyszerű azonosítás és karbantartás szempontjainak megszervezésére. Belső célú rendszer létrehozásakor a belső tervezés konfigurációját használhatja, amikor a rendszert külső ügyfelek számára hozza létre. Az Eclipse AJDT segítségével egyszerűen új konfigurációs konfigurációkat hozhat létre.
Szempontok és tervezési minták
jan / AODPs / be tudod tölteni a GOF.5 csoport sablonokat implementáló kódot. 5 Nicholas Lesiecki írta az IBM developerWorks webhelyének tervezési mintáit is. 6 A cikkben részletesebb leírást ad a cikkhez képest.
Tekintsen egy nagyon egyszerű példát az AspectJ szabványos Adapter tervezési mintájának végrehajtására.
A 8. ábra az Adapter sablon egységesített modellezési nyelv (UML) diagramját mutatja. Ebben a sablonban az ügyfélnek szolgáltatásra van szüksége, és ehhez egy lekérdezést kell létrehoznia. Számos szolgáltató lehet, és mindegyiküknek eltérő szolgáltatási neve vagy nem szabványos követelményei lehetnek, amelyeket a megkereső félnek teljesítenie kell. A jó objektumorientált formatervezés feltételezi, hogy a szolgáltatási kérelem beillesztésre kerül a célinterfészbe, a program az interfészhez, és szükség esetén létrehoz egy adaptert, amely közvetítő szerepet játszik az ügyfél és a szolgáltatás között (az ábrán ez Adaptee).
8. ábra Adaptermintázat
Az adapter használatának megközelítése meglehetősen ésszerűnek és célszerűnek tűnik. De mit kell tennünk egy olyan elavult rendszer esetében, amelyet nem terveztünk sablonokkal vagy adapterekkel? E rendszerek fejlesztői nem vették észre a jövőbeni változás lehetőségét. A szolgáltatáshívások szétszóródhatnak az alkalmazás során. Hogyan lehet új, javított szolgáltatást bevezetni? Szempontok nélkül valószínűleg vissza kell állítania a rendszer forráskódját, meg kell keresnie az összes szolgáltatáshívást, fejlesztenie kell egy adaptert, és végre kell hajtania az Adapter mintát. A régi szolgáltatáshoz tartozó hívások számától függően ez meglehetősen unalmas feladatot jelenthet. A forráskód visszaállítása és javítása méltó cél, de nem mindig lehetséges ilyen luxus. Meg kell elégednünk a kódok elosztásával, ez a legjobb dolog, amit rövid idő alatt lehet tenni.
Ebben az esetben létrehozhat egy AOP-verziót az Adapter-sablonból, amely azonnal megoldja a problémát, és lehetővé teszi, hogy előrelépjen egy szervezett és jobban tervezett rendszerhez.
A 9. ábrán egy egyszerű kliens látható a szolgáltatás használatával. A szolgáltatás visszaadja a távolságot egy pontról a jelenlegi Ügyfél objektumra.
9. ábra Egy egyszerű ügyfél
A szolgáltatás interfésze külön módszert ír le:
Egy új, továbbfejlesztett szolgáltató egy olyan módszerrel rendelkezik, amely kissé eltérő névvel és más paraméterekkel rendelkezik. A kezelőfelület:
Olyan adaptert kell létrehoznunk, amely a régi szolgáltatáshoz tartozó hívások között található, megkapja a megfelelő érveket az új szolgáltatáshoz, felhívja az új szolgáltatást, és az eredményeket visszaküldi az ügyfélnek. Az ügyfél nem változik egyszerre. Az ehhez szükséges szempont a 10. ábrán látható.
10. ábra. Az adapter új szolgáltatásának hívása
Ügyeljen az egyszerűségre. Kijelentünk egy pontcut, hogy azonosítsuk az egyes hívásokat a forrásszolgáltatás használatának módjára. Ezután használja a tanácsot körül, hogy cserélje ki ezt a hívást egy új szolgáltatáshívással, miután megkapta a szükséges információkat a hívó ügyféltől.
Ez a megközelítésnek előnyei és hátrányai vannak. Először is, ezt az egyszerű szempontot alkalmazva módosíthatja az alkalmazási kódot. Ön is kapszulázhatja a kapcsolatot, hogy hívjon egy szolgáltatást egy helyről. Most, ha az új szolgáltatást egy új szolgáltatás helyettesítjük, csak a szempont kódot kell megváltoztatni. Ez egy előnyösebb egy megbízhatóbb rendszer számára.
A fő hátrány az, hogy a régi kliens még mindig a rendszerben marad, még akkor is, ha nincs használatban. Ha van idő (ami úgy tűnik, hogy soha nem létezik), akkor valószínűleg vissza kell állítania és vissza kell állítania a rendszer forráskódját a szabványos Adapter sablon használatához. A legkisebb, megváltoztathatja a source service ofService metódust olyan kódra, amely visszatérít egy értéket, például 0.0, mivel ezt a módszert soha nem fogják hívni.
Alkalmazás szakmai szinten
Eddig világosan korlátozott, de még mindig hasznos példákat tekintettek az AOP alkalmazására. Felmerül a kérdés, de mennyire jó ez a módszer. Rámutatok, és röviden ismertetem egy jól ismert példát. A részletesebb vizsgálat egy másik cikk írását igényli.
Talán néhányan ismernek a Spring Framework, 7 olyan alkalmazás-infrastruktúrát, amely támogatja a vállalati alkalmazások fejlesztését. A Spring Framework többszintű J2EE környezetet kínál összetett vállalati alkalmazások építéséhez. Az AOP a Spring egyik legfontosabb technológiája. A tavaszi közösség kifejlesztette saját aspektusorientált implementációját, ami lehetővé teszi, hogy komplex logikát alkalmazzanak a kódra a futás idején, és ne a fordítási idő alatt, ahogyan az AspectJ-ban. De vannak olyan integrációs funkciók, amelyek lehetővé teszik, hogy könnyedén bevonhassák az AspectJ-ot a tavaszi keretrendszerbe.
Jelenleg a Spring-et számos szervezetnél használják, hogy jobban tervezzenek és kevesebb fejlesztési időt igényelnek. Becsléseim szerint ez kiváló példa arra, hogyan alkalmazzuk a szempontokat a valódi problémákra. 8
Mit tehetek tovább?
Véleményem szerint a jövőben az AOP része lesz a szoftverfejlesztő eszköztárnak. Nem tudom, hogy elérjük-e azt a pontot, amikor a fő tervezési mechanizmussal az AOP használatával hozunk létre rendszereket, de úgy vélem, megtaláljuk a módokat az objektumorientált projektek meglévő aspektusainak felhasználásával. Számos dolog felgyorsíthatja a folyamatot.
Először is szabványos stabil AOP megvalósításokra van szükség. Ez a folyamat már megkezdődött. Az 5-ös verzió AspectJ egyesíti az AOP Java - AspectJ és az AspectWerkz két legnépszerűbb nyelvét. Más nyelveken, például a C ++ szabvány szerinti megvalósítások is segítenek.
Másodszor, olyan mutatókat kell kifejleszteni, amelyek igazolják az AOP alkalmazások hatékonyságát az egyes rendszerekhez. Például az AOP használatával a tervezési minták újbóli megvalósítása jobb lesz-e mint a hagyományos objektumorientált sablonok? Milyen esetekben vannak a sablonok, és melyikben vannak - nem? Milyen mutatókra van szükség ahhoz, hogy információkat szerezzen, és miként fejlesztheti ezeket a mutatókat? Egy egyszerű megközelítés ideje, amikor az objektumvázolt (vagy bármely más általad választott) rendszert jónak tartották (), elhaladt. Empirikus adatokon alapuló projekt- és végrehajtási megoldásokat kell létrehozni. 9
Harmadszor, folytatni kell az AOP-t támogató eszközök fejlesztését. Örömmel jelenthetem be, hogy az új Eclipse AJDT egy csodálatos eszközkészlet. Ezek az eszközök javították a szempontok hatékony és ésszerű használatához szükséges támogatást. Az eszközöknek támogatniuk kell az új technológiákat is.
A szempontokat fenn kell tartani. Még nem váltak a fő alkalmazások közé, de egyre közelebb kerülnek hozzá minden nap. Azt javaslom, hogy ismerkedjen meg a szempontokkal és alaposan tanulmányozza azokat.
jegyzetek
3 GOF Csoport - Erich Gamma, Richard Helm, Ralph Johnson és John Vlissides, aki a "Design Patterns" című könyvet írta. Ez egy alapvető könyv a tervezési minták;
7 Ha az AOP-t használó olvasók megosztani szeretnék tapasztalataikat, és adatokat szolgáltatnak az AOP mutatókra vonatkozó kutatásomról, kérjük, lépjen velem kapcsolatba.