Megtörtént már, hogy alkalmazásodat új tulajdonságokkal kellett kiegészitened néhány nap alatt? Találkoztál már az osztályok rugalmatlanságával? Mi is az az AOP? Nos, ezen problémák megoldása.
Egy-egy 'Hello World'-nél összetettebb alkalmazás tervezése során a fejlesztőnek egyszerre több feladatot kell egyidejűleg megoldania: kritikus műveleteket végez tranzakciókon belül, hitelesíti a felhasználót és logolja az eseményeket. A feladat végrehajtója így - általánosan egy objektum - nem csak azzal foglalkozik, ami valójában a feladata.
Minden objektum (illetve osztálya) amire ez igaz, veszít a rugalmasságából, újrafelhasználhatóságából, könnyed fejleszthetőségéből, ráadásul, ugyanazon kód felmérhetetlenül sokszor előfordul osztályokon át szétszóródva.
Az intuitív megközelítés talán jobban rávilágít a problémára. Tekintsük ehhez az alábbi osztályt:
class FontosOsztály {
private Logger myLog = new Logger(); private int FontosAdat; ... public fontosMetodus(...) {
myLog.add("[A fontos metodus elindul]"); ... //Teszünk sok fontosat myLog.add("[A fontos metodus lefutott]");
}
}
Első ránézésre nincs vele semmi baj. Pedig van.
A megoldás nagy hátránya az, hogy osztályunk nem csak azzal foglalkozik, ami rá tartozna: a naplózásnak semmi köze az osztály feladatához. Ennek megoldására hagyományosan két út létezik:
A Logger osztály - amikor már nincs rá szükség, például az add() metódus hívásakor - nem csinál semmit.
Az érintett kódrészleteket eltávolítjuk, szükség esetén a visszatesszük.
Aki már bíbelődött ilyesmivel, azonnal rávághatja az ellenérveket: az első eset használhatatlan, ha bizonyos helyeken szükség van a naplózásra és bizonyos helyeken nincs, a második pedig két fájlnál többől álló rendszer esetén már problémássá válhat: az ember lusta, a programozó a nap bizonyos részében ember...Továbbá: ne felejtsük el, ez egy igen egyszerű, lazán összegabalyodott példa volt, try - catch - (finaly) szerkezetet bele sem tettünk!
A tervezési minták - mint például a Decorator - bizonyos mértékig megoldást adnak erre a problémára (így a felsorolásban akár harmadikként is szerepelhetne), de - legjobb esetben is - fájlok túlburjánzásához vezethetnek, amibe a programozó és tervező egyaránt belefulladhat.
A refactoring is járható út lehetne, de túl sokat kell hozzá gépelni és gondolkodni az alkalmazás evolúciójának már korai szakaszában is. Lássuk be, ezt ha egy mód van rá, el kéne kerülni.
Röviden fogalmazva: az objektumorientált programozás nagy előnye, hogy egységbe zárva az adatot és a rajtuk végzendő mőveleteket megóvja azokat a felügyeletlen változásoktól - viszont megfosztja az objektumot attól, hogy a környezetétől függően viselkedjék. Továbbá az OO paradigma kiváló a feladatok modularizációjára, ellenben azok elkülönített implementálására nem. Ezekre nyújt - többek között - megoldást az AOP.
