I min nya outtömliga källa till visdom, J2EE AntiPatterns, har jag hittar ytterligare guldkorn som på ett närgånget sätt kan relateras till mitt dagliga arbete. De har dessutom så fina namn att de förtjänar att nämnas bara för det: Mirage och Exodus! Nästan lika bra som DataVision!

Mirage är ett anti-pattern som är otroligt enkelt att förklara: man struntar i att det finns en massa färdiga verktyg för att mappa Java-objekt mot databaser (boken nämner främst CMP, men det finns ju miljoner O/R-mappers), och implementerar sitt eget ramverk i JDBC.

I några enstaka fall måste man kanske göra det, för att man vill hämta saker från flera tabeller, men här finns ju hönan- eller ägget-problematiken: Hämtar man saker från flera tabeller med handhackad JDBC för att det O/R-mappern är för dålig, eller gör man det för att man har gjort det hittills.

Nu är inte saker i verkligheten så enkla och svartvita (för mycket PL/SQL), men det är värt att komma ihåg att någon har tyckt hela förfarandet är ett anti-pattern.

Exodus(en refactoring) är mer jordnära och delvis relaterad till Mirage. Historisk evidens har visat att det är otrligt enkelt att hamna i situationer där man av en eller annan anledning tillverkar egna DTO:s (som t ex är resultatet av en JOIN) i tid och otid. Själv är jag skyldig till detta och kallar mig “agil”. Detta får dock konsekvensen att man inte direkt kan avgöra var dessa mini-väldigt-super-specifika DTO:s ska skapas. Enligt principen “Är det fult, så är det fel“, blir det väldigt smärtsamt att lägga till skapandet av dessa i en mera generell DAO, som ansvarar för ett koncept eller en tabell.

Exodus identifierar detta problem och kommer med lösningen: Allt sådant smuts ska brytas ut till en factory som använder generella DAO:s och får skapa hur dåliga och specifika DTO:s som helst. Det är inte riktigt så boken beskriver mönstret, men det är andemeningen. Jag har länge letat efter en lösning på detta problem…