Tervezési mintákról szóló nagy sikerű könyv (ha valakinek kell az könyv melléklet CD-je, ami a teljes könyvet is tartalmazz – az a kiadás, amiből a magyar fordítás is készült, asszem – szóljon és felteszem a nettre pár órára) egyik jelmondata, hogy öröklés helyett részesítsük előnyben az objektum kompozíciót. Ugyanúgy el tudjuk vele érni azt, amit az örökléssel, azaz ki tudjuk terjeszteni az objektum felelősségi körét, de ezt fordítási idő helyett futási időben.
Mit is jelent ez nálam? Egyébként bemutatom az Validation Framework új release-ének feature-eit. (imádni való az ilyen beszéd, nem?)
Szóval acélom az volt, hogy olyan validátor készítsek, ami adat egy jól konfigurálható alapot ahhoz, hogy POJO-t lehessen validálni úgy, hogy ne kelljen ténylegesen egyetlen sor Java kódot sem írni.
Első gondolatom a az volt, hogy szépen leszármaztatom az AbstractValidátor-t egy PropertyValidátro-ba, ami kezeli a JavaBeaneket és azok propertieit, majd annak konkrét gyerekei fogják a tényleges validálást elvégezni.
Idővel érett bennem egy kicsit a dolog és észrevettem, hogy ha kiveszem egyetlen property ellenőrzését végző felelősségi kört egy másik objektumba, akkor nincs is szükségem ilyen mély hierarchiára. Magyarul leválasztottam a feleslegesen többlet felelősséget az osztályról. Lazán elhelyeztem egy Checker-be.
De itt is van öröklés! De ugyebár nem is arról van itt szó, hogy kerülnünk kellene, hanem inkább arról, hogy jól válasszuk meg a felelősségi köröket, és úgymond ne terheljük „felesleges” felelősségekkel az osztályunkat. A célt ugyanúgy elértük, de egyszerűbben és átláthatóbban.
Mi az, ami hiányzik? Tulajdonképpen semmi. Implementálva is van. De a végső célt még nem értem el, mégpedig azt, hogy programozás nélkül lehessen a validálást elvégezni. Még egy Assembler cuccot is készítek, ami valószínűleg egy sima property fájlból veszi a reguláris kifejezéseket és abból már lazán „egy sorral” ki lehet nyerni a szép új és roppant jól használható validátort.
Mire lesz újra internetem addigra kész is lesz.
