Komponensek egy¨uttm˝uk¨od´ese webalkalmaz´as k¨ornyezetben J´on´as Rich´ard Debreceni Egyetem, Informatiai Int´ezet T-Soft M´ern¨okiroda KFT
[email protected]
Kivonat Napjainkban az ´elet valamennyi szerepl˝oj´enek el˝onye sz´armazik abb´ol, ha az interneten tud k¨ oz¨ olni ´es fogadni inform´ aci´okat, majd ezen inform´aci´okat j´ol szervezetten k´epes felhaszn´ alni. Ehhez elengedhetlen egy szoftver-infrastrukt´ ura kidolgoz´asa, amelyet ma a web-alkalmaz´ asok val´ os´ıtanak meg. Ebb˝ol fakad´oan a web-alkalmaz´asok gyors ´es r¨ovid ´eletciklusokkal rendelkez˝ o szoftverfejleszt´esi folyamata elengedhetetlen ahhoz, hogy id˝oben reag´aljunk a k¨ ovetelm´enyekre. A web-alkalmaz´ asok ilyen fejleszt´es´et t´amogatja a komponens-alap´ u szoftverfejleszt´es, amelynek sz´ amos ´ aga van. Egyesek a komponensek ´altal´anos reprezent´aci´oj´aval foglalkoznak, m´ asok a komponensek felhaszn´ al´as´aval el´ert u ¨zleti profitot tartj´ak szem el˝ott, emellett l´eteznek a m´ odos´ıthat´ os´ agra kihegyezett komponens-architekt´ ur´ak, stb. Cikkemben a komponensek egy¨ uttm˝ uk¨od´es´et szeretn´em bemutatni c´ımszavakban, majd megvizsg´ alni, hogy hogyan lehet az egy¨ uttm˝ uk¨od´esb˝ol fakad´o f¨ ugg´eseket u ´gy finom´ıtani, hogy az ne menjen a m´ odos´ıthat´ os´ ag rov´as´ara. Tov´abb´a p´eld´at l´athatunk arra, hogy hogyan lehet szepar´ alni egym´ ast´ ol a komponens felel˝oss´eg´et ´es a rendszer funkcionalit´asait, ha sz¨ uks´eg van r´ a. Ezt az aspektus-orient´alt programoz´as seg´ıts´eg´evel fogom bemutatni, p´eld´akon kereszt¨ ul.
1.
Bevezet´ es
Napjainkban a t´arsadalom informatiz´al´asa r´ev´en a szoftverfejleszt´es m´eg nagyobb jelent˝os´eggel b´ır, mint eddig, hiszen az ´elet minden ter¨ ulet´en sz¨ uks´eg van biztons´agosan m˝ uk¨od˝o, dokument´alt, fejleszthet˝o szoftverre. Az objektum-orient´alt programoz´as olyan szoftverfejleszt´esi paradigma, amely megold´ast adott a nagym´eret˝ u alkalmaz´asok kezelhet˝os´eg´et illet˝oen, de nem oldott meg sz´amos olyan probl´em´at, amelyek az alkalmaz´as funkcionalit´as´ara vonatkoznak. Az objektumok a val´os vil´ag entit´asait reprezent´alj´ak, teh´at az objektum-orient´alt programoz´as az entit´asok felel˝oss´eg´et emeli ki. Egy alkalmaz´as viszont funkcionalit´asok ¨osszess´egek´ent
1
foghat´o fel, ´es legt¨obb esetben egy objektum az´ert rendelkezik bizonyos met´odussokkal, tulajdons´agokkal, mert egy funkci´ot ez seg´ıt megval´os´ıtani. Az alkalmaz´as ´eletciklusa sor´an el˝ofordul, hogy az alkalmaz´ast u ´j funkci´okkal kell kiterjeszteni, vagy megl´ev˝o funkci´okat kell m´odos´ıtani. Az alkalmaz´asban megjelen˝o funkci´ok t¨obb objektum, komponens, modul egy¨ uttm˝ uk¨od´es´enek eredm´enyek´eppen j¨onnek l´etre, teh´at ha m´odos´ıtani kell egy funkci´ot, akkor legrosszabb esetben az egy¨ uttm˝ uk¨od´esben r´esztvev˝o ¨osszes komponenst m´odos´ıtani kell. Ez term´eszetesen megnehez´ıti egy alkalmaz´as t¨obb fejleszt˝o ´altal v´egzett p´arhuzamos fejleszt´es´et. Cikkemben szeretn´ek bemutatni egy technol´ogi´at, amellyel a komponensek k¨oz¨otti kommunik´aci´o ¨osszefoghat´o, annak ´erdek´eben, hogy az k¨onnyebben m´odos´ıthat´o legyen. Tov´abb´ a megvizsg´alom, hogy hogyan lehet a kommunik´aci´ot egys´eges´ıteni, ´ıgy egyszer˝ ubb´e tenni.
2.
Komponensek
A komponensek j´ol elk¨ ul¨on´ıthet˝o k´odr´eszletek, amelyek ¨on´all´oan fejleszthet˝ok, dokument´alhat´ok, u ¨zembehelyezhet˝ok. Cikkemben els˝osorban forr´ask´od´ u komponensekkel (azon bel¨ ul is Java nyelv˝ u komponensekkel) foglalkozom, de vizsg´alatra ker¨ ul a nem forr´askod´ u komponensek k¨oz¨otti kommunik´aci´o egyszer˝ us´ıt´ese is. Ahhoz, hogy meg´erts¨ uk cikkemben mit ´ertek a kommunik´aci´o alatt, n´ezz¨ unk meg egy p´eld´at. Tegy¨ uk fel, hogy van egy fejlesztend˝o szoftver¨ unk, amelyben sz´amos olyan funkci´ot val´os´ıtunk meg, amelyek az u ¨zembe helyezett szoftver eset´eben nem kell, hogy m˝ uk¨odjenek. Ilyen p´eld´aul a napl´oz´as (bizonyos esetekben az u ¨zembehelyezett rendszern´el is fontos ez a funkci´o), az u ´gynevezett el˝o- ´es ut´ofelt´etel vizsg´alatok met´odusok v´egrehajt´asa el˝ott ´es ut´an, stb. Vil´agos, hogy ezek a fejleszt´es sor´an fontosak ´es egy teszt ut´an, egy m˝ uk¨od˝o rendszer eset´en nem sz¨ uks´egesek, csak lass´ıtan´ak a szoftvert. Nem neh´ez bel´atni, hogy a napl´oz´assal foglalkoz´o h´ıv´asok a teljes rendszer forr´as´at ´athatn´ak, ´ıgy el´eg nagy energia lenne kit¨or¨olni ezeket a h´ıv´asokat a k´odb´ol, de ha m´eg egy programoz´ o ezt a feladatot ell´atn´a, akkor a k¨ovetkez˝o rendszerfriss´ıt´es eset´en szint´en meg kell oldania ezt a probl´em´at.
2.1.
Aspektus-orient´ alt programoz´ as
Az ilyen esetek megold´as´ara fejlesztett´ek ki az aspektus-orient´alt programoz´ast ([1]). Az AOP k¨oz´eppontj´aban az aspektus ´all, amelyet a rendszer egy funkci´ojak´ent, dolgak´ent foghatunk fel. Az´ert j¨ott l´etre ez a paradigma, mert ´eszrevett´ek, hogy a rendszerben megtal´alhat´ok olyan funkci´ok is, amelyek komponensekt˝ol f¨ uggetlen¨ ul jelennek meg, ´ıgy az ¨or¨okl˝od´esi- ´es interf´eszhierarchia seg´ıts´eg´evel ezeket a probl´em´akat nem lehet megoldani. Az AspectJ ([2]) egy olyan nyelv, amely a Java aspektus-orient´alt kiterjeszt´esek´ent j¨ott l´etre. Az AspectJ-ben ´ırt k´od byte-k´od kompatibilis a Java nyelv˝ u oszt´alyokkal, ´ıgy egy AspectJ program futtathat´o a hagyom´anyos JVM-eken is. Ez nagyban el˝oseg´ıti az AspectJ nyelv terjed´es´et, hiszen megtehetj¨ uk, hogy a rendszer¨ unk egy r´esz´et ´ırjuk csak ´at aspektus-orient´alt 2
m´odon, majd u ¨zembehelyezz¨ uk, ´es fokozatosan ´atgondoljuk a kritikus r´eszeket. A szakirodalom ez refactoring-nak nevezi ([3][4]) ´es olyan esetekben kell alkalmazni, ha aspektusokkal szeretn´enk ¨osszefogni az ism´etl˝od˝o kommunik´aci´okat m´ar megl´ev˝o rendszer¨ unkben. Az AspectJ fogalomrendszere a k¨ovetkez˝o elemekb˝ol ´all: • joinpoint: j´ol meghat´arozott k´odr´eszletek, p´eld´aul met´odusok, konstruktorok, tulajdons´agok, oszt´alyok, stb. • pointcut: felt´eteleket alapj´an k´odr´eszleteket v´alaszthatunk ki vele, p´eld´aul: egy joinpoint seg´ıt´es´eg´evel kijel¨olt met´odus h´ıv´asa, tulajdons´ag ´ert´ek´enek m´odos´ıt´asa, stb. Mit¨obb a pointcut-okat logikai ¨osszek¨ot˝ojelekkel kombin´alva, ¨osszetett felt´eteleket adhatunk meg, p´eld´aul: olyan met´odusok h´ıv´asa, amely neve add sz´oval kezd˝odik, de a met´odus maga nem param´etern´elk¨ uli, stb. • advice: egy k´odr´eszlet, amely egy pointcut eset´en lefut. • aspect: az el˝obbi h´arom ¨osszess´ege, bele´ertve a strukt´ ur´alis m´odos´ıt´asokat is.
2.2.
Kommunik´ aci´ os mint´ ak
Webalkalmaz´asok eset´en akkor haszn´alhatjuk sikerrel az AOP-t, ha megtal´aljuk ´es kiemelj¨ uk a kommunik´aci´o sor´an felmer¨ ul ism´etl˝od˝o mint´akat. Ilyenek p´eld´aul a bean-ek kommunik´aci´oja a JSP lappal, illetve az adatb´azissal, stb. Ezeket a probl´em´akat bizonyos nyelvek, keretrendszerek inherens m´odon kezelik, de ilyen keretrendszereket haszn´alva meg kell tanulnunk egy speci´alis ´ keretrendszerre ´att´erve egy u szkriptnyelvet. Uj ´jabb nyelvet kell megtanulnunk ´es ´ıgy tov´abb. R´aad´asul ezek a nyelvek nem ´altal´anos c´el´ uak, ´ıgy a fejleszt´es sor´an k¨onnyen belebotlunk olyan probl´em´aba, amely megold´as´at nem t´amogatj´ak.
3.
Mint´ ak AspectJ-vel
N´ezz¨ uk meg hogyan lehet az el˝obb eml´ıtett k´et gyakran felmer¨ ul˝o, sok egyforma k´odot tartalmaz´o mint´at implement´alni az AspectJ seg´ıts´eg´evel.
3.1.
Bean-JSP kommunik´ aci´ o
Tegy¨ uk fel, hogy a van egy bean-¨ unk, amely egy sz´amla adataival foglalkozik. A bean a JSP oldalr´ol megkapja a sz´amla azonos´ıt´oj´at (invoideId), majd lek´erdezi az adatb´azisb´ol a sz´amla le´ır´o attrib´ utumait. Ekkor a bean a k¨ovetkez˝ok´eppen n´ezhet ki: public class Bean { private String parameterInvoiceId;
3
public void execute(){ ... ResultSet r = statement.executeQuery("select * from" + "invoice where id = ’" + parameterInvoiceId + "’"); ... } } A parameterInvoiceId v´altoz´o ´ert´eke az InvoiceId k´er´esi param´eter ´ert´eke kell legyen. Ezt term´eszetesen bele´ırhattuk volna a bean-be, de ha t¨obb 10-20 ilyen ´ert´eket kell ´atadni, akkor a l´enyegi k´od elt˝ unik a kommunik´aci´os k´odok k¨oz¨ott. Defini´aljunk egy RequestGetter interf´eszt, amely jelzi, hogy egy bean rendelkezik egy k´er´es objektummal. interface RequestGetter { public ServletRequest getRequest(); public void setRequest(ServletRequest request); } A k¨ovetkez˝o k´od egy ParameterGetter nev˝ u aspektust defini´al, amely funkci´oja a k¨ovetkez˝o: ha egy bean defini´alja a RequestGetter interf´eszt, akkor b´armely parameter el˝otaggal rendelkez˝o attrib´ utum ´ert´ek´ere val´o hivatkoz´askor, nem a t´enyleges ´ert´eket fogjuk megkapni, hanem a parameter ut´ani (eset¨ unkben InvoiceId) n´evvel rendelkez˝o k´er´esi param´eter ´ert´ek´et. aspect ParameterGetter { declare parents: Bean implements RequestGetter; private ServletRequest RequestGetter._rq = null;
// (1) // (2)
public ServletRequest RequestGetter.getRequest(){ return _rq; } public void Request.setRequest(ServletRequest r){ _rq = r; } after(Bean b, HttpServletRequest request): execution(public Bean.new(..)) && this(b) && 4
// (3)
cflow( execution(public void *.HttpJspBase._jspService( HttpServletRequest, HttpServletResponse) ) && args(request) ){ b.setRequest(request); } String around(RequestGetter rg): // (4) get(String RequestGetter+.parameter*) && this(rg) { String attributeName = thisJoinPointStaticPart.getSignature().getName(); String parameterName = attributeName.substring(9); return rg.getRequest().getParameter(parameterName); } } Az (1)-gyel jel¨olt k´od azt jelenti, hogy a Bean oszt´aly defini´alja a RequestGetter interf´eszt. A (2)-vel kezd˝od˝o k´odr´eszlet egy u ´gynevezett t´ıpusok k¨oz¨otti deklar´aci´o (inter-type declaration), amely azt mondja, hogy ha egy oszt´aly implement´alja a RequestGetter interf´eszt, akkor rendelkezni fog egy rq nev˝ u attrib´ utummal, egy getRequest ´es egy setRequest met´odussal, amely implement´aci´oj´at az aspektus adja meg. Teh´at az aspektus megold´ast ad arra is, hogy hogyan lehet egy interf´eszt automatikusan implement´alni 1 . A (3)-mal jelzett k´od egy tan´acs (advice), amely a Bean oszt´aly b´armely konstruktor´anak v´egrehajt´od´asa ut´an h´ıv´odik meg, akkor ha ez a v´egrehajt´od´as a HttpJspBase oszt´aly (minden JSP lap ˝ose) jspService met´odus´anak v´egrehajt´asa k¨ozben t¨ort´enik2 . A this(b) hat´as´ara a sz´oban forg´o objektumot a b azonos´ıt´oval ´erhetj¨ uk el, az args(request) kifejez´essel pedig egy h´ıv´as/v´egrehajt´as argumentumait lehet neves´ıteni, ´ıgy a request a param´eterben ´atadott HttpServletRequest ´ert´eke lesz. A tan´acs t¨orzse be´all´ıtja a bean k´er´es objektum´at. Ezzel l´athattunk egy p´eld´at egy komponens autmatikus k¨ornyezet-detekt´al´as´ara. A (4)-gyel jelzett k´od egy m´asik tan´acs, amely szerint ha hivatkoz´as t¨ort´enik egy parameter el˝otaggal rendelkez˝o v´altoz´o ´ert´ek´ere egy olyan oszt´aly eset´eben, amelyik implement´alja a RequestGetter interf´eszt, akkor ehelyett hajt´odjon v´egre a k¨ovetkez˝o k´od. A k´od k¨ornyezet´er˝ol a thisJoinPointStaticPart hordoz struktur´alis inform´aci´ot, ´ıgy megtudhatjuk a sz´oban forg´ o attrib´ utum nev´et. A kilencedik karaktert˝ol a k´er´esi param´eter nev´et kaphatjuk meg, amely 1
Erre a Java nyelvben is l´ athatunk p´eld´ at a Serializable interf´esz eset´eben, hiszen ott is van a szerializ´ alt oszt´ aly m¨ og¨ ott be´ep´ıtett funkcionalit´ as. 2 A cflow a control flow r¨ ovidit´ese.
5
´ert´ek´et elk´erhetj¨ uk, hiszen ismerj¨ uk a k´er´est (request). Ha szeretn´enk, hogy a Bean ne ´ıgy m˝ uk¨odj¨on, akkor az (1)-sel jelzett sort kell kit¨or¨olni, illetve ha szeretn´enk, hogy m´as oszt´alyok is ´ıgy viselkedjenek, akkor ugyanitt vessz˝ovel elv´alasztva, ´es/vagy wildcard karakterek seg´ıts´eg´evel t¨obb oszt´aly nev´et is megadhatjuk.
3.2.
Bean-adatb´ azis kommunik´ aci´ o
Az interakt´ıv webalkalmaz´asok fejleszt´esekor gyakran felmer¨ ul egy adatb´azist´abla b˝ov´ıt´ese, m´odos´ıt´asa, vagy az abb´ol val´o t¨orl´es. Ez a feladat a t´abla ismeret´eben el´eg j´ol algoritmiz´alhat´ o probl´ema, ´ıgy joggal gondolhatjuk, hogy k´odgener´atorral elk´esz´ıthet˝ok a t´abl´akat manipul´al´ o k´odok. Elk´esz´ıthet˝ok, de ut´ana a gener´alt k´odok karbantart´asa lehetetlen (´ ujragener´aljuk, vagy belejav´ıtsunk a gener´alt k´odba). Hogyan seg´ıt ezen a probl´em´an az aspektus-orient´alt programoz´as? Defini´aljuk a k¨ovetkez˝o interf´eszt: public interface DataModifier { } Azon bean-ek, amelyek manipul´alni szeretn´ek az adatb´azist, jelezz´ek azzal, hogy implement´alj´ak a DataModifier interf´eszt. Ezut´an ha b˝ov´ıteni szeretn´e a bean az invoice t´abl´at, defini´alja a k¨ovetkez˝o u ¨res t¨orzs˝ u met´odust. public void add_invoice(String _invoice_id, Timestamp create_date){ } Az add el˝otag jelzi, hogy b˝ov´ıteni szeretn´enk egy t´abl´at, majd a t´abla nev´et tartalmazza a met´odus. Form´alis param´etereiben pedig a t´abla mez˝oinek a nev´et kell felsorolni u ´gy, hogy az els˝odleges kulcs neve el´e egy al´ah´ uz´as jel ker¨ ulj¨on (a m´odos´ıt´asn´al ´es a t¨orl´esn´el tudnunk kell mely mez˝ok r´eszei a kulcsnak). import java.sql.*; import org.aspectj.lang.reflect.*; public aspect Database { void around(): execution(public void DataModifier+.add_*(..)){ try { Class.forName( "org.gjt.mm.mysql.Driver" ); Connection conn = DriverManager.getConnection( "jdbc:mysql://127.0.0.1:3306/test" ); 6
Object [] args = thisJoinPoint.getArgs(); MethodSignature ms = (MethodSignature) thisJoinPointStaticPart.getSignature(); String methodName = ms.getName(); String tableName = methodName.substring( 4 );
// (1)
// (2)
String [] pnames = ms.getParameterNames(); Class [] ptypes = ms.getParameterTypes(); StringBuffer sql = new StringBuffer(); sql.append( "insert into " ).append( tableName ).append( " (" ); for ( int i = 0; i < pnames.length; i++ ){ sql.append( pnames[i] ); if ( i < pnames.length - 1 ) sql.append( ", " ); } sql.append( ") values (" );
// (3)
for ( int i = 0; i < pnames.length; i++ ){ sql.append( "?" ); if ( i < pnames.length - 1 ) sql.append( ", " ); } sql.append( ")" );
// (4)
// (5) PreparedStatement st = conn.prepareStatement( sql.toString() ); for ( int i = 0; i < ptypes.length; i++ ){ if ( ptypes[ i ].equals( String.class ) ) st.setString( i + 1, ( String ) args[ i ] ); if ( ptypes[ i ].equals( Integer.TYPE ) ) st.setInt( i + 1, ( ( Number ) args[ i ] ).intValue() ); } st.execute(); st.close(); conn.close(); } } catch ( Exception e ){ 7
e.printStackTrace( System.err ); } } A Database aspektus megval´os´ıtja a fent v´azoltakat, n´ezz¨ uk meg hogyan! Az around-advice jelzi, hogy a DataModifier-t implement´al´o oszt´alyok add -sal kezd˝od˝o met´odusainak h´ıv´asakor az eredeti k´od helyett a tan´acs t¨orzs´et hajtsuk v´egre. Miut´an csatlakoztunk az adatb´azishoz, az (1)-sel jelzett k´od a met´odush´ıv´askor ´atadott argumentumok ´ert´ek´et tudja meg. Majd (2)-sel jelzett k´odban a met´odus szignat´ ur´aj´anak lek´erdez´ese ut´an meg tudjuk hat´arozni a t´abla nev´et, hiszen az a 4. karaktert˝ol kezd˝odik a met´odus nev´eben. Ezut´an a met´odus param´etereinek nev´et ´es t´ıpus´at tudjuk lek´erdezni. Sajnos m´as tulajdons´agot nem (final-e vagy sem), ez´ert kell a kulcsr´esz attrib´ utumok neveit al´ah´ uz´assal kezdeni. Ezt a Java 1.5 ([5]) verzi´oj´aban kiel´eg´ıtett JSR-175-¨os k´er´es ([6]) metadata eszk¨oze k´epes megoldani. Ezut´an az SQL utas´ıt´asnak a sz¨oveg´et kell ¨ossze´all´ıtani, a param´eterek nevei a t´abl´aban szerepl˝o mez˝ok nevei lesznek (3), majd a param´eterek ´ert´ekeit el˝ok´esz´ıtett SQL utas´ıt´assal fogjuk behelyettes´ıteni (4). A param´eterek t´ıpus´at ismerv´en tudjuk, hogy a param´eter ´ert´ek´et mely JDBC t´ıpusba kell konvert´alni ´es ´atadni. Az (5)-sel jelzett k´od sz¨oveges ´es eg´esz ´ert´ek˝ u param´eterek ´ert´ekeit tudja ´atadni az el˝ok´esz´ıtett utas´ıt´asnak. Ezut´an v´egrehajthatjuk az adatmanipul´aci´os utas´ıt´ast.
4.
Konkl´ uzi´ o
A cikkben v´azolt m´odszerrel elv´egezhetj¨ uk a komponensek k¨oz¨otti olyan kommunik´aci´ot, amelyek ism´etl˝od˝oek, opcion´alisak. Ehhez term´eszetesen fel kell fedezn¨ unk, hogy a megoldand´ o probl´ema milyen aspektusokat tartalmaz. Ezt a legegyszer˝ ubben use-casek, felhaszn´al´oi esetek ´es a kollabar´aci´os diagrammok elemz´es´evel v´egezhetj¨ uk el. Ezut´an meg kell vizsg´alni, hogy mely objektumok, komponensek vesznek r´eszt az aspektusban, amely mint l´atjuk ford´ıt´asi id˝oben t¨ort´enik. ´Igy az aspektus statikus lesz, de ez a legt¨obb esetben nem probl´ema, hiszen az u ¨zembehelyezett rendszerekn´el a rendszer eg´esz´et, vagy egy j´ol meghat´arozott modult friss´ıtenek, de nem aspektusokat. ´ esem szerint az aspektus-orient´alt programoz´ast sikerrel lehet alkalmazni, ha j´ol megErz´ hat´arozott esem´enyekre ism´etl˝od˝o k´odokat kell v´egrehajtani. ´Igy elker¨ ulhetj¨ uk a k´odgener´al´ast az esem´enyvez´ert programoz´as megfelel˝o haszn´alat´aval. A nyelvi t´amogat´as m´eg nem t¨ok´eletes, hiszen az aspektusok ´ır´asakor a Java 1.5-¨os verzi´oja m´eg nem volt el´erhet˝o, ´ıgy f¨ol¨oslegesen k´esz´ıtett, met´odusn´elk¨ uli interf´eszekkel kellett min˝os´ıteni az oszt´alyokat. Az aspektus-orient´alt programoz´as eszk¨ozeivel megold´odni l´atszanak olyan komponensalap´ u programoz´asban megjelen˝o probl´em´ak, amelyeket eddig neh´ezkes volt kezelni. Ilyen a komponensek k¨ornyezet´enek detekt´al´asa, onnan inform´aci´ok ´atv´etele, illetve a hiba jelz´ese, 8
ha a k¨ornyezet nem megfelel˝o (komponens be´ep´ıthet˝os´ege). A komponens tud k¨ornyezet´et˝ol f¨ ugg˝oen viselkedni, hiszen a cflow seg´ıts´eg´evel megadhatjuk, hogy valamilyen h´ıv´as hat´asa alatt vagyunk vagy sem. A komponenseket aspektusok k¨otik ¨ossze, ˝ok val´os´ıtj´ak meg a kommunik´aci´ot, ´ıgy a kommunik´aci´oval foglalkoz´o k´odokat nagys´agrendekkel k¨onnyebben lehet v´altoztatni mint eddig. Az aspektus-orient´alt programoz´as m´eg nem fejl˝od¨ott ki teljesen, de l´atszik, hogy mindenk´eppen egy paradigmav´alt´as el˝ott ´allunk.
Hivatkoz´ asok [1] Aspect-Oriented Software Development Community, http://aosd.net [2] AspectJ Project, http://eclipse.org/aspectj [3] Aspect-Oriented Refactoring: Part 1 – Overview and Process, Ramnivas Laddad, http://www.theserverside.com/articles/article.jsp?l=AspectOriented RefactoringPart1 [4] Aspect-Oriented Refactoring: Part 2 – The Techniques of the Trade, Ramnivas Laddad, http://www.theserverside.com/articles/article.jsp?l=AspectOriented RefactoringPart2 [5] Java 2 Standart Editon, Sun Microsystems, http://java.sun.com/j2se/1.5.0/ [6] Java Specification Request: A Metadata Facility for the JavaTM Programming Language, www.jcp.org/jsr/detail/175.jsp
9
