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…

När jag programmerade mot Spring Batchs klass JobParameters och anropade getString fick jag ett fett NPE. Javadocen för metoden var inte särskilt hjälpsam, så jag kollade i källkoden och hittade detta:

/**
* Typesafe Getter for the String represented by the provided key.
*
* @param key The key to get a value for
* @return The <code>String</code> value
*/
public String getString(String key){
    return parameters.get(key).toString();
}

/**
* Typesafe Getter for the String represented by the provided key. If the
* key does not exist, the default value will be returned.
*
* @param key to return the value for
* @param defaultValue to return if the value doesn't exist
* @return the parameter represented by the provided key, defaultValue
* otherwise.
*/
public String getString(String key, String defaultValue){
    if(parameters.containsKey(key)){
       return getString(key);
    }
    else{
        return defaultValue;
    }
}

Det är någonting som stör mig i den här konstruktionen. Vad är dock inte säkert. Till exempel skulle det vara helt fel att implemetera getString(key) som den är gjord nu, om den andra varianten inte fanns.

Givet att vi accepterar att vi behöver två metoder, så är det fortfarande fel att införa denna koppling. Vet inte ens något fancy name för denna typ av koppling.

Om vi nu ignorerar detta och accepterar att man måste veta namnet på sin nyckel, annars får man ett NPE (varför inte ett IllegalArgument eller IllegalState om metoden är så strikt?), så blir det fortfarande konstigt, eftersom det inte fungerar som i typ 99% av de andra fallen, och framför allt i Javas egna API.

Eller så är författarna av Spring Batch så briljanta att de vågar vägra null och det som stör är att man är då gammalmodig. Någonting stör i alla fall.

Nu är det bevisat! Läser man tillräckligt många böcker kommer man att hitta sitt favoritpattern, eftersom alla vill göra en claim for fame. Själv har jag hittat antimönstretDataVision i boken J2EE AntiPatterns.

Antimönstret gör sig synligt när databasen får bestämma designen av applikationen och visar sig via följande symptom:

Överflöd av pseudokomponenter: geggiga komponenter som bara bär en massa data.

Dysfunktionell komponentobjektmodell: överkomplicerad och svårunderhållen modell.

Ökade underhållskonstnader: det är svårt att implementera ny funktionalitet.

Fram tills jag hittade detta antimönster var mitt förtreoende för boken sådär. Nu när jag ser att det stämmer in till 200% på ett visst system jag arbetar med, så blir boken så mycket roligare att läsa.

Så glöm Singleton och kom ihåg DataVision!