Short talk about designing user friendly APIs in C#

1. Fluent API design
Joar Øyen
@joaroyen
www.joaroyen.com

2. Innpakking av kompleks tredjeparts bibliotek
Slike biblioteker har typisk funksjonalitet du ikke trenger
Hvorfor?
Veileder brukeren (dvs. utvikleren) hva som er semantisk
gyldig i henhold til forretningsregler, og ikke bare hva som
syntaktisk er mulig
Lesbarhet

3. Alternativ til
über-klasse som parameter
Når? 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)

4. Mikroskopisk domenespesifikt språk
Hvordan? 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

5. Log.Message(
"Ingen tilgang til {0}. Verifiser at serveren er tilgjengelig.",
FilePath);
Eksempler
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");

6. Fra ett metodekall til 5 interfaces og 11 klasser
Hva har vi Fra «über klasse» og «overloads from hell» til «train wreck»
oppnådd?
Syntaktisk sukker
Log Message
Error
Exception
Warning To
Information
UnhandledException
Det mest vanlige blir veldig enkelt
Veiviser for utviklere for avanserte scenarioer
Lesbar og testbar kode

7. Vær konsistent
Generelt Følg Microsofts retningslinjer
råd 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

8. Antall kodelinjer er ikke indikatoren på hvor kompleks
løsningen er - det er leserens forståelse av koden som
Budskap 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