Egy ideje mar gondolkoztam a megfeleloen alkalmazott Listenerek elhelyezesen a kodban, ahelyett, hogy oda nem illo responsibility-t kezeljek a kodot teljesen elcsufito felteteles elagazasokkal. Ma reggel azonban a vonathoz setalva egy konkret pelda kapcsan egy – az eddiginel is otletesebb – megoldas jutott eszembe.

Eloszor, fejtsuk ki az alapproblemat. A MindGraph szandekaim szerint alkalmas lesz tobb, egyidejuleg megnyitott dokumentum kezelesere. Nyilvan lesz mindig egy aktiv, meg nehany masik a hatterben, amiket megfeleloen navigalva aktivva tudunk tenni, az aktualis aktivat passzivalva. Amikor “uresen” elinditjuk a MindGraph-et, letrehoz nekunk egy uj, ures dokumentumot. Mi tortenik azonban, ha ekkor betoltunk egy masik dokumentumot?

Szandekaim szerint ekkor az uj, ures dokumentum bezarodik, es a frissen betoltott dokumentum lesz az egyetlen megnyitott, aktiv darab. Ellenben, ha mar van egy megnyitott, nem ures dokumentumunk, es akkor toltunk be egy korabban lementettet, akkor nem akarjuk bezarni az elozot, csak passzivalni. Ergo, kepesnek kell lennunk arra, hogy megmondjuk, ez a dokumentum volt-e mar szerkesztve, vagy meg nem.

Az egyik lehetseges megoldas az, hogy fogjuk az aktualis aktiv dokumentumot, es megnezzuk, hogy van-e benne content. Ennek a megoldasnak tobb elonye is van, es siman lehet, hogy ezt valasztom, de azert kifejtem a masik megoldast is, ami eszembe jutott.

A programlogika, ami a scene-t modosithatja, be van csomagolva egy action osztalyba. Az osztalyoknak nyilvan egysegesitett interface-e van. A trukkos megoldas, amit kitalaltam, egy nagyon kulonleges wrapper osztaly.

A wrapper lenyege ugye az, hogy ugyanolyan interface-t biztosit, mint a becsomagolt osztaly, es annak is passzolja tovabb a fuggvenyhivasokat, csak ad hozza valami kis extra funkcionalitast. (van egy masikfele wrapper is, de en most erre gondolok)

Kitero: Ez kicsit olyan, mint egy peldanyra kihegyezett AOP, ahol a wrapperbe agyazott logika maga egy Aspect. De nyilvan az AOP ennel sokkal tobb, es nem veletlenul vannak teljes retegek kiemelve aspektusba.

Az en wrapper osztalyom egy dologban mas, mint a normalis: Az elso hivas utan “kicsomagolja” magat, azaz a logika vegrehajtasa utan kicsereli onmagat a becsomagolt osztalyra. Ezzel azt erjuk el, hogy a wrapperben hivott kod csak egyszer tud lefutni, es onnantol gyakorlatilag nem letezik a kodban, azaz nem is lassitja a futast.

Nyilvan kell egy kis trukkozes, hogy a sorrend megorzesevel ki tudjuk cserelni az akciot egy masikra, es nem is biztos, hogy szukseg van egy ennyire bonyolult kodra, hiszen ha egy sima feltetelvizsgalatot teszunk be helyette, a JIT alapu virtualis gep ugyis gondoskodni fog rola, hogy az elagazas megfelelo aga fusson, elhanyagolhato overhead-del. De azert erdemes elgondolkozni rajta, hogy milyen lehetosegek szuletnek egy ilyen megoldassal, hiszen az egesz programunk sokkal dinamikusabba valik. (hiszen nem csak onkicsomagolas lehet, hanem on-the-fly factory, meg onbecsomagolas, es hasonlok)

Ha lesz konkret kod ra, lehet, hogy bevagok par reszletet.