- Validerer du med true og false? Slutt med det!

Skriver du ofte funksjoner som dette?

fun isValidEmail(email: String): Boolean {}

Altså funksjoner som validerer et eller annet, og returnerer true eller false ettersom om reglene dine tilsier at det som sendes inn er “gyldig” eller ikke? Også bruker du de videre sånn som dette?

fun sendEmail(email: String) {
if !(isValidEmail(email)) {
// return error code, throw exeption etc
}
// handle valid email case
}

Slutt med det! (Gitt at du bruker et programmeringsspråk med et fornuftig typesystem).
I stedet: Skriv funksjoner som ikke bare validerer det du sender inn, men som i tillegg tar vare på resultatet!

Annen retur

Tar vare på resultatet? Hva betyr det? Jo — det er egentlig ganske enkelt: I stedet for å returnere true eller false når du sjekker om noe er gyldig — returner heller en type som representerer den nye, validerte tilstanden til det du sendte inn, sånn som dette:

data class EmailValidationError(reason: String)
data class ValidEmail(email: String)

fun validateEmail(email: String): Either<EmailValidationError, ValidEmail> {}

Funksjonen gjør det samme som tidligere, altså tar inn en epost-adresse, og validerer at den er gyldig. Men i stedet for å returnere true eller false som resultat, så returnerer den enten typen “EmailValidationError”, eller typen “ValidEmail”.

Den store fordelen

Den store fordelen med å gjøre det slik, er at nå, hver eneste gang du håndterer en epost-adresse i koden din, så er du garantert å ha en gyldig epost!

I stedet for å sende rundt en string, som kanskje eller kanskje ikke har blitt sendt gjennom “isValidEmail” på et eller annet tidspunkt, så kan du sende typen “ValidEmail”, som du er trygg på at inneholder det den skal. Du må bare sørge for at et sted, “så langt ut” i koden som mulig, typisk i en controller, eller det “ytterste” stedet du snakker med et system du ikke har kontroll over, konverterer epost-strengen til "ValidEmail", ved å kjøre den gjennom funksjonen din, også vipps har du spart deg for mange fremtidige timer med debugging, bugs, null-pointers og rare exceptions. ✨

Prøv selv

Dette patternet kan brukes i så å si alle statisk-typede språk, som Java, C#, Go og Typescript, og ikke bare i Kotlin som jeg har brukt som eksempel her.

“Either” + prorammeringsspråket ditt i google bør gi deg en god start!

Så anbefaler jeg også på det sterkeste å lese artikkelen Parse, don’t validate av Alexis King, som forklarer konseptet “type driven design” på en langt mer utfyllende måte enn dette korte eksemplet.

Kos deg med typesikker koding! 🥳