Fluent API design

Joar Øyen

@joaroyen

www.joaroyen.com

Hvorfor?

Innpakking av kompleks tredjeparts bibliotek

Slike biblioteker har typisk funksjonalitet du ikke trenger

Veileder brukeren (dvs. utvikleren) hva som er semantisk

gyldig i henhold til forretningsregler, og ikke bare hva som

syntaktisk er mulig

Lesbarhet

Når?

Alternativ til

über-klasse som parameter

lang liste av overloads

deklarativ konfigurasjon

Biblioteker som i stor grad skal benyttes av andre

For komplekse API som brukes sjelden (dvs. at

kompleksiteten brukes sjelden)

Hvordan?

Mikroskopisk domenespesifikt språk

Builder pattern

Det mest vanlige skal alltid resultere i enklest (minst) kode

Ordenes rekkefølge er viktig

Ett eller flere startpunkt

Interface med tilhørende implementasjon

Statisk wrapper

Extension metoder

Eksempler

Log.Message("Ingen tilgang til {0}. Verifiser at serveren er tilgjengelig.",FilePath);

Log.Message(42, "Ingen tilgang til {0}. Verifiser at serveren er tilgjengelig.",FilePath);

Log.Message(Resources.NoAccessToResource, FilePath);

Log.Exception(new TimeoutException("Test"), "Message");

Log.UnhandledException(new TimeoutException("Message"));

Log.Warning.Exception(new TimeoutException("Message"));

Log.Information.To("Debug").Message("Message");

Debug.Message("Message");

Hva har vi

oppnådd?

Fra ett metodekall til 5 interfaces og 11 klasser

Fra «über klasse» og «overloads from hell» til «train wreck»

Syntaktisk sukker

Det mest vanlige blir veldig enkelt

Veiviser for utviklere for avanserte scenarioer

Lesbar og testbar kode

Log Message

Exception

UnhandledException

Error

Warning

Information

To

Generelt

råd

Vær konsistent

Følg Microsofts retningslinjer

Design Guidelines for Developing Class Libraries

http://msdn.microsoft.com/en-us/library/vstudio/ms229042(v=vs.100).aspx

Framework Design Guidelines

http://books.google.no/books/about/Framework_Design_Guidelines.html?id

=39d1wZ598ecC&redir_esc=y

Budskap

Antall kodelinjer er ikke indikatoren på hvor kompleks

løsningen er - det er leserens forståelse av koden som

indikerer hvor elegant løsningen er implementert

Når du lager kode som skal brukes av andre - invester i

brukervennlighet slik du ville ha gjort for en bruker som

sitter i brukergrensesnittet