Det sies at å programmere mot interface er god praksis. Spesielt når man kobler sammen applikasjonen via IoC(Inversion of Control) container som for eksempel Spring, så er det lissom en selvfølge at man skal bruke interfacerer og klasser. Hvor tanken er at brukere av klassen forholder seg til et interface og hvor IoC containeren injecter en bestemt implementasjon av interfacet. Tenken er god, men hva når man kun har en implementasjon av disse interfacene?
Trelags arkitektur (med domeneobjekter)
La oss tenke oss en trelags arkitektur, hvor man kjører enhets/integrasjonstester helt igjennom helt ned til en testdatabase (som opprettes helt automatisk f.eks via DbUnit). Hva er da hensikten med å lage og vedlikeholde disse interfacene? Slik jeg ser det er det ingen vits. Det skaper kun ekstra arbeid. Mange filer, og mer tungvint utvikling.
Jeg har akkurat opplevd dette hvor jeg har gjennomført programmert mot interfacer, men nå har fjernet alle, og det ser veldig ryddig ut.
Men så kan du spørre, hva om ønsker å injecte dummy test-klasser da? Jo, fint. Det er bare å refakturere. For eksempel så har MyService brukt CustomerDao, og vi ønsker å lage en dummy implementasjon av CustomerDao som heter CustomerDaoDummy. All right. Endre navn på CustomerDao til CustomerDaoImpl og lag et interface som heter CustomerDao som de ulike klassene implementerer. Brukere av klassen trenger man ikke å endre.
Min anbefaling er derfor å ikke programmere mot interface med mindre man trenger det. Du får renere og mer oversiktlig kode på denne måten. Dette er henhold til agile prinsipper og naturligvis KISS prinsippet (Keep It Simple, Stupid).
PS: Det skal sies at dersom man lager biblioteker og funksonalitet som krysser applikasjoner så kan det være hensiktmessig og ryddig med interfaces, men det er ikke tilfellet i en vanlig enkel applikasjon.
