Fluent API design Joar Øyen @joaroyen www.joaroyen.com
Dec 05, 2014
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