– Slutt å bruke interfaces på alle tjenester!

Det har blitt en automatikk i .Net-verdenen: Skal du lage en tjeneste, må du ha et interface. 

Det tar både unødvendig tid og kode – og verst av alt, vi slutter å teste det som faktisk betyr noe.

I moderne .Net-utvikling ser vi ofte at KI-agenter og KI-maler automatisk genererer et interface for hver eneste tjeneste som opprettes. Tanken er god: Vi vil følge SOLID-prinsippene og legge til rette for "Clean Code". 

Men i iveren etter å følge prinsipper som Interface Segregation Principle (ISP), som sier at klasser ikke skal tvinges til å implementere metoder de ikke bruker, har vi endt opp i den andre grøfta.

Vi lager nå enorme mengder interfaces som bare har én eneste implementasjon.

Forretningslogikk skal ikke erstattes

Hovedargumentet for å bruke et interface er abstraksjon – muligheten for å bytte ut én implementasjon med en annen uten at resten av systemet merker det. Dette er kritisk for ting som databaseaksess (Repository Pattern), eksterne API-er eller utsending av e-post.

Men forretningslogikken din er selve kjernen i applikasjonen. Den skal som regel ikke erstattes. 

Hvis du har en OrderProcessingService som inneholder de spesifikke reglene for hvordan firmaet ditt håndterer ordrer, finnes det ingen "alternativ" måte å gjøre dette på som krever et interface. Forretningslogikken er sannheten i systemet ditt.

Mocking-fellen: Hva tester du egentlig?

Den største synden skjer i test-prosjektene. 

Vi har lært at vi skal "mocke" avhengigheter. Men hvis tjenesten din hovedsakelig består av forretningslogikk og du mocker den bort, fjerner du selve årsaken til at du tester. 

Du ender opp med å teste "rørleggerarbeidet" , det vil si at det gjøres et såkalt metodekall, en instruksjon i programmeringen, mens de kritiske beregningene blir ignorert. 

Ved å bruke faktiske klasser, forbedres testbarheten betraktelig.

– Utviklere overdriver faren ved vendor lock-in

– Prosjekter går sjelden dårlig fordi man valgte feil skyplattform, skriver utvikler Steinar Kollerud.

Skill: Smart Service Registration

Siden agenter i dag ofte lager alle tjenester med et interface som standard, må vi gi dem bedre instrukser. 

Her er et forslag til en "Selective Abstraction Skill" som du kan legge inn i dine system-instrukser eller agent-definisjoner:

• Analyse av tjenestetypen: Før du genererer en klasse, skal du kategorisere den som enten Infrastruktur/Ekstern kilde eller Ren Forretningslogikk.
• Interface-forbud for forretningslogikk: Hvis klassen inneholder interne forretningsregler og beregninger, skal den ikke ha et interface. Registrer klassen direkte i DI-containeren som seg selv.
• Fokuserte interfaces (ISP): Hvis det er behov for et interface (for eksterne integrasjoner eller utskiftbare komponenter), skal du aldri lage ett stort, "oppblåst" interface. Del det opp i små, rolle-spesifikke grensesnitt (f.eks. IWorkable, IApprovable) slik at klasser ikke tvinges til å implementere metoder de ikke trenger.
• Test-strategi: Instruer agenten til å skrive tester som bruker den faktiske implementasjonen av forretningslogikk, fremfor å generere mocks av tjenester som ikke representerer eksterne grensesnitt.

Gå tilbake til røttene

Interface Segregation er et fantastisk verktøy når man har store, oppblåste kontrakter som tvinger klasser til å implementere unødvendig kode. Det hjelper oss å holde koden modulær og enkel å oppdatere. Men vi må slutte å bruke det som en "default" for absolutt alt.

Min oppfordring er enkel:

1. Registrer klassen direkte: I .Net sin Dependency Injection-container kan du fint registrere en tjeneste med services.AddScoped(); uten et interface.
2. Bruk interfaces for eksterne grensesnitt: Behold dem for databaser, tredjeparts API-er og infrastruktur.
3. Test den faktiske logikken: Ved å bruke den faktiske klassen i integrasjonstester (eller ved å la logikken være i rene domenemodeller), sikrer du at du faktisk verifiserer forretningsreglene dine.

Ved å tørre å droppe interfacet der det ikke trengs, får du mindre kode å vedlikeholde, enklere navigasjon, færre filer å navigere i, og tester som faktisk gir verdi.

Ti grep som forbedrer .NET-kodebasen din

– Det handler om friksjon. Hvor lett det er å lese koden, endre den og stole på den, skriver utvikler Steinar Kollerud. Her er hans .NET-tips.