Självrannsakan: Inversion of Control bara för testbarhetens skull? Och vadådå, skulle det vara så farlig?

När man skriver kod som ska enhetstestas är det lätt att hemfalla åt att slentrianmässigt se till att injicera beroenden i en klass istället för att kapsla in dem, bara för att man vet att klassen kommer att bli lättare att testa. Som allt annat man gör slentrianmässigt finns det såklart en fara i det, själva definitionen av slentrian innebär att man gör något utan att tänka efter.
Så för att förhoppningsvis stilla den gnagande känslan av oro tänkte jag i alla fall för mig själv fundera igenom vad jag tycker. Det handlar alltså om hur IoC står i förhållande till inkapsling. Är det alltid ok att injicera beroenden i sin klass?
Man kommer kanske lätt undan om man kan motivera injiceringen med att man på sätt och viss bara följer strategy-mönstret. I ärligheten namn kräver detta att man faktiskt har tänkt sig att injicera olika implementationer av beroendet även utanför testkoden. Ett annat fall där det känns designmässigt korrekt att bryta ut beroendet är när man kan motivera det med någon form av loose coupling (svag koppling? ) eller separation of concerns.
Men om man till slut kommer fram till att man skulle vilja använda IoC primärt för att göra en klass testbar så har jag bestämt mig för helt enkelt se på det pragmatiskt; visst bryter man inkapslingen och då gäller det att väga nackdelarna med detta mot fördelarna med ökad testbarhet. Om man ser på inkapslingen som ett sätt att göra det svårare för programmerare att använda en klass ”fel”, det vill säga genom att injicera ett annat beroende än vad som ursprungligen var tänkt, så håller jag med min förre detta kollega Göran Krampe som en gång konstaterade något liknande ”Jag har sett mer problem med klasser där man inte fått göra det man vill  än med klasser där man får”. Det ligger väl i linje med idén om att man måste lita på att de som ska använda ens kod vet vad de sysslar med. Med detta sagt så är det naturligtvis inte så att testbarhet alltid går före inkapsling. Snarare gäller det att vid varje tillfälle ställa dessa två mot varandra och känna efter vad som är viktigast. Och min känsla är att testbarheten ofta i praktiken är mer värd än inkapslingen.

Annonser

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s


%d bloggare gillar detta: