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.

For de som ennå ikke har hørt det så har Spring gjort en relativt betydelig endring i deres release policy. Den nye policien sier at etter 3 måneder av en major release så vil kun de som betaler få nye bug-fix releaser. Så for eksempel når 3.0.0 slippes, og etter tre måneder så er man på 3.0.2,  så vil kun de som betaler få nye oppgradering som 3.0.3 osv.  Kildekoden vil likevel være tilgjengelig i SpringSources repository, men de som ikke betaler må laste nede og bygge selv.

Jeg ser ikke dette som et stor problem, men som en påminnelse om at selv om det er open source så betyr det ikke at det er gratis. I dette tilfellet så er kildekoden fortsatt gratis, men SpringSources koordinering av bugfixer må man betale for.

Det jeg tror vil skje er at noen i open source miljøet vil ta på seg å koordinere og lage bug-releaser selv.  Hvordan dette vil påvirke tilbakemelding og rapportering av bugs vil tiden vise.

Motivasjonen for dette er for meg tydelig, SpringSource ønsker flere betalende brukere og presser kundene på denne måten.  Noen vil argumentere for at firmaer som bruker Spring i kritiske applikasjoner burde uansett ha en supportavtale, men det som det har vært tilfelle med Spring er at bug-fix release har vært så gode at man ikke har trengt support, og veldig få har tatt seg ”bryet” med å betale.  Så med mindre gode alternativer for Spring kommer opp så vil nok flere firmaer nå ta seg bryet med å betale for varen.

Det jeg er nyskjerrig på er hvordan dette vil påvirke Maven bygging når releaser ikke lengre vil være i åpne repositorier.  Med mindre vi får en ny måte å gjøre dette på vil dette medføre mye rot som Maven til nå har løst.

Spring har nå vært en de facto standard for de aller fleste java prosjekter, hvor man har inkludert biblotekene selv om man ikke har brukt dem så mye. Jeg tror nå med den nye vedlikeholds policien så vil man tenke seg litt mer om før man inkluderer dette flotte biblotektet. Dette er litt trist, fordi etter min mening er Spring noe av det viktigste som har skjedd i java enterprise verdenen.

Lang diskusjon finnes her.

For alle som jobber med Lucene indexer av og til har vi nå laget et nytt verktøy som kan gjøre hverdagen litt enklere. Luclipse er en eclipse plugin som gir deg tilgang til dine Lucene indexer direkte fra Eclipse. Hittil har alternativet vært å bruke Luke, som har sine mangler. Bl.a. huser ikke Luke hvilke indexer du tidligere har åpnet, og brukergrensesnittet kan være noe overveldende og forvirrende før man har brukt det en del. På sikt er Luclipse tenkt å ha mye den samme funksonaliteten som Luke som sikkert flere kjenner, men forhåpentligvis vil Luclipse gi et enklere og mer effektivt brukergrensesnitt.  Vi ser også for oss å legge til funksjonalitet for å kunne teste sine egne alalyzere. Luclipse har vi valgt å legge ut som et opensource prosjekt, slik at andre kan være med å bridra til at vi får et bedre verktøy for jobbe med lucene. Den første versjonen og kildekode kan lastes ned på http://sourceforge.net/projects/luclipse/