I de to forrige postene, Utenfra-og-inn programmering og Avhengigetsisolering (a.k.a Mocking), har jeg forklart hvordan jeg praktiserer testdreven utvikling. Denne gangen gjør jeg et forsøk på å vise det i praksis, en slags “tutorial” om du vil. Det er selvfølgelig en overhengende fare for at jeg produserer en svært lang blogpost, men om du har lyst til å bli med meg og oppleve “Mockist TDD“ i praksis så er du i alle fall svært velkommen.

Jeg dokumenterer steg for steg hva jeg gjør, og om du vil må du gjerne kode oppgaven parallelt med meg – det vil du nok lære mest av. I så fall trenger du NUnit og Moq (eller annet testrammeverk og mockingrammeverk du er komfortabel med), db4objects, samt Visual Studio. Jeg har ikke lagt ved den ferdige løsningen, det er selve prosessen som er poenget her.

Når jeg gjør testdreven utvikling forsøker jeg å utvikle i så små steg som mulig, og jeg hopper mye frem og tilbake mellom test og produksjonskode. Jeg har også en tendens til å foretrekke mange, små klasser som jobber sammen for å løse oppgaver, til fordel for større klasser med mer kompleks logikk. Noen vil kalle det overkill, jeg kaller det et fleksibelt design. Du kan gjøre deg opp din egen mening.

Oppgaven

“På vår fantastiske webside skal man kunne registrere seg som ny bruker med brukernavn og passord. Passordet skal selvsagt lagres kryptert. Når man har en brukerkonto skal man kunne logge inn.”

Ok, det hørtes ikke så vanskelig ut – de fleste utviklere har gjort dette noen ganger før. Asp.net har jo også kontroller og providere som gjør dette veldig enkelt. Men vi skal bruke denne oppgaven til å øve på TDD, så vi later som om alt det der ikke finnes, glemmer hva vi har gjort tidligere, og setter i gang.

En liten påminnelse: Det finnes hundrevis av måter å implementere dette på, og det finnes hundrevis av måter å gjøre TDD på. Dette er min fremgangsmåte, slik jeg foretrekker akkurat nå. Det finne singen fasit, og neste gang ville jeg kanskje ha gjort det anderledes. Så ikke kopier meg, men reflekter over hvorfor jeg gjør det jeg gjør, og du vil sikkert lære noe på veien.

Forberedelser

Jeg fyrer opp Visual Studio og åpner et nytt prosjekt basert på Asp.net Web Application templaten. Vi innbiller oss at dette er den eksisterende websiten vi skal utvikle den nye “featuren” for. For å gjøre dette enkelt vil alt opprettes i dette ene prosjektet, inkludert testene – normalt ville jeg ha fordelt elementene i løsningen i diverse moduler.

Den første testen, en kontroller og et view

Oppgaven vi har fått er todelt: Brukerregistrering og brukerautentisering. Registrering kommer naturlig før autentisering, så vi starter med det. Er du en utvikler som ikke er vandt til TDD og utenfra-og-inn programmering kan det nå være fristene å tenke at du har lyst til å starte med å opprette en bruker-klasse, eller kanskje definere hvordan databasen skal se ut. Det skal vi ikke gjøre. Ditt første instinkt skal være å skrive en test, en test som passerer om brukerregistreringen fungerer.

La oss opprette en testklasse – jeg velger å gi den det merkelige navnet When_registering_a_new_user:

Jeg ser for meg at jeg vil ha en eller annen form for controller som tar seg av registreringen. Controlleren kan kommunisere med et view hvor brukeren skal taste inn et brukernavn og passord og trigge registreringen. Når registreringen er gjennomført kan controlleren kommunisere dette tilbake via viewet. La meg forsøke å skrive en test:

Ingen av disse klassene finnes enda. Dette er helt vanlig når man gjør TDD; man forsøker først å finne ut hvordan klassene bør se ut – deretter implementerer man dem.

Jeg er ikke helt fornøyd med hvordan jeg må trigge registration request ved å kalle en metode på viewet, og jeg like heller ikke at jeg må implementere to ulike klasser for denne testen – jeg ønsker å fokusere på én ting om gangen. Men hvis jeg foreløpig lar viewet være et abstrakt interface, og tar i bruk mockingrammeverket (Moq) kan vi få dette til å bli litt bedre. Jeg endrer testen:

Det vil være mye rødt i editoren nå siden det fortsatt ikke er noen av disse klassene, metodene eller eventene som eksisterer, men det lærer vi oss raskt å leve med, så forsøk å se bort i fra det.

Denne testen synes jeg ble litt bedre. På linje 18 trigger jeg et RegistrationRequested event, som jeg tenker vil tilsvare eventet som fyres når brukeren klikker på “register” knappen på websiden. På neste linje verifiserer jeg at SetRegistrationResult har blitt kalt med argumentet “true”. Jeg vil nemlig at controlleren skal plukke opp registreringsforespørselen og kalle den metoden om alt går som det skal. I stedet for å verifisere på tilstand verifiserer jeg nå adferd.

Det er på tide å gjøre noe med alle de røde advarslene, så nå vil jeg opprette controlleren og viewet. Siden jeg bruker CodeRush er dette kun noen få tastetrykk – bruker du ikke noe slikt verktøy må du gjøre det for hånd. Dette er hva jeg kommer opp med.

Nå kompilerer prosjektet vårt, men kjører jeg testen vil den selvfølgelig feile, for SetRegistrationResult vil aldri bli kalt. Og det er helt perfekt. I TDD følger man et mønster som heter “Red, Green, Refactor”, som innebærer at vi først skal sørge for å lage en test som feiler. Det har vi oppnådd.

En grønn test

Så hvordan kan vi komme til neste steg – en vellykket test? Jo, det er veldig enkelt, selv om det virker som en helt idiotisk ting å gjøre:

Jeg kaller rett og slett SetRegistrationResult i konstruktøren til controlleren. Hvorfor det? Jo, nå vet jeg at testen fungerer – at testen blir grønn hvis SetRegistrationResult kalles. To av tre steg er gjennomført, og vi kan gå igang med det litt vage steget “refakturering”.

Men hva med eventet som trigges? Det var jo det som skulle føre til registreringen. Stemmer det! Jeg kunne ha skrevet en ny test som passet på at SetRegistrationResult ikke ble kalt uten at eventet ble trigget, men akkurat nå synes jeg ikke det er nødvendig. Jeg gjør denne endringen med den ene testen jeg har:

.. jeg kjører testen på nytt etter endringen for å være sikker på at jeg ikke har ødelagt noe; den er fortsatt grønn, så alt er ok.

Test nummer 2: User repository

Men det skjer jo ingen registrering her. Hmmm. En registrering innebærer å opprette og lagre en ny bruker, ikke sant?! (Som du ser spiller jeg dum, og forplikter meg dermed ikke til et konkret design før det er absolutt nødvendig.) Ok, da trenger vi en eller annen form for Repository som kan lagre nye brukere. Jeg får skrive en ny test – kan jo ikke begynne å implementere noe nytt uten…

Jeg lager en ny mock som skal representere en repository, og sender den også inn til controlleren. I linje 47 kontrollerer jeg at Insert har blitt kalt, og at det ble sendt inn et User objekt. Hverken UserRepository eller User eksisterer enda.

Det meste av testen ligner på den forrige testen, så DRY-prinsippet (kanskje det aller viktigste prinsippet innen softwareutvikling) tvinger meg til å trekke ut det som er felles. Jeg ender opp med denne testklassen:

For at dette skal kompilere må jeg gjøre tre ting; opprette UserRepository, fikse controllerens konstruktør til å ta inn en repository, og opprette en User klasse. Noen CodeRush-shortcuts senere har jeg opprettet følgende:

Prosjektet kompilerer igjen. Vår første test passerer fortsatt, men den nye testen gjør ikke det, så det får vi gjøre noe med. Vi må rett og slett sørge for at den nye brukeren lagres:

Der, nå er begge testene grønne. Kontrolleren lagrer en ny bruker til repositorien, og sier fra til viewet at det er gjort. Men den mangler noe veldig sentralt. Trenger vi ikke noe mer input? Hvor er brukernavnet og passordet?

Har du noen gang programmert så mye adferd uten å lage en eneste public property? Er det ikke interessant hvordan TDD lar oss fokusere på adferd? Men nå er det kanskje på tide å legge til i alle fall brukernavn og passord. Men først må vi ha en test for dette. Den siste testen vi skrev verifiserer at brukeren lagres til basen. Hva om vi legger til å validere selve brukeren som legges til også – at den har riktig navn f.eks.? Jeg forsøker meg på dette ved å endre testen til dette her:

Jeg bruker litt Moq-magic til å sette opp en callback som tar vare på brukeren som sendes til repositorien, og sjekker at navnet på den er “Kong Håkon”. Men hvor har jeg fått dette navnet fra? Det skal jo brukeren sende inn.., via viewet selvfølgelig. Så vi setter opp dette også:

Jeg forventer nå at viewet har en Username property, og at den vil returnere “Kong Håkon” for oss når den blir forespurt. Registreringsjobben skal da overføre dette navnet til brukeren som lagres. Peace of cake! Jeg oppretter de to propertiene jeg trenger for å få kompilert, kjører testen én gang for å se det røde lyset, implementerer litt mer logikk i kontrolleren, og har to grønne tester igjen.

PS: Jeg har forøvrig trukket ut litt logikk fra When_doing_a_registration() og plassert det i en SetUp-metode – hvis ikke hadde jeg fått en null-ref exception i linje 53.

Passordkryptering

Nå kunne jeg gjort det samme for passord som for brukernavn, men oppgaven sa at jeg skulle kryptere passordet. Det er derfor viktig at passordet som lagres IKKE er det samme som sendes inn fra viewet. Jeg jobber litt til med testene:

Nei, dette føles ikke særlig riktig. Når jeg tenker over det er hashing av passord et helt annet ansvar, noe kontrolleren kan deligere til noen andre. Ved å utnytte det kan jeg skrive en enkel test som validerer at passordet hashes, mens jeg utsetter selve hash-logikken.

Jeg har begynt å gå litt raskere frem nå, men jeg regner med at du klarer å henge med. Jeg har lagt til en ny avhengighet, PasswordHashService, som jeg injecter i controller-konstruktøren. Og så skriver jeg en ny test som verifiserer at HashPassword kalles. Noen sekunder senere får jeg dette til å kompilere og testen til å passere ved å gjøre følgende..

Password settes i linje 44. Jeg bruker to ulike properties som ikke finnes enda.., så jeg oppretter dem. Done!

En konkret hasher

Vi har nå laget en fungerende controller, men ingen av de objektene den sammarbeider med eksisterer enda – de ble alle “mocket ut” i testene. Vi kan nå jobbe oss innover. Jeg velger å ta PasswordHashService først. Jeg skriver selvsagt tester før produksjonskode.., og her er den første:

Jeg fant hashen til denne setningen i Wikipedia’s artikkel om MD5, så jeg tenkte den kunne være et greit utgangspunkt for å teste algoritmen. Litt cut n’ paste fra nettet og prøving og feiling gir meg følgende implementasjon som passerer testen:

En konkret repository

Neste interface jeg trenger en konkret implementasjon av er UserRepository. For å implementere den trenger jeg et persisteringsmedium, en eller annen form for database. Det enkleste jeg vet om er å bruke en objektdatabase, db4objects, så det vil jeg gjøre her. Jeg kan enkelt sette opp en test som oppretter en database, lagrer en bruker, kontrollerer at jeg kan hente brukeren ut igjen, og rydder opp ved å slette basen. Jeg gjør dette i små steg, men her er alt i en batch:

Jeg vil ha en konkret UserRepository som jeg vil kalle Db4oUserRepository. Jeg vil sende en instans av en objektdatabase inn via konstruktøren (IObjectContainer er et db4objects interface). I setup-metoden oppretter jeg en ny filbasert database og selve repositorien, og i teardown disposer jeg databasen og sletter filen.

Selve testen lagrer en ny bruker i repositorien, og så bruker jeg Linq 2 Db4o for å hente ut alle brukere fra basen, sjekke at det finnes én-og-bare-én bruker (ved å kalle Single()), og kontrollere at brukernavnet er riktig. Vær oppmerksom på at du må legge til “using Db4objects.Db4o.Linq” for å få Linq-spørringen i linje 69 til å kompilere. Vil du vite mer om Db4objects kan du lese min blogpost om dette fantastiske rammeverket.

Følgende enkle implementasjon tilfredstiller testen over:

Et konkret view

Det eneste som gjenstår nå for å ha en fungerende brukerregistrering er å lage et konkret view. Dette er den eneste biten jeg ikke bryr meg om å skrive tester for – det er somregel ikke verdt innsatsen, sålenge forretningslogikken er separert ut av viewet. Jeg oppretter en ny Web User Control, kaller den Registration.ascx, og dropper inn to TextBox’er og en Button.

Og her er code-behind, hvor jeg lar Registration arve fra UserRegistrationView:

Denne approchen er opprinnelig inspiret av Phil Haack’s blogpost om Supervising Controller i ASP.NET. Initaliseringen av kontrolleren som foregår i Page_Load knytter sammen alle objektene som trengs for å registrere en bruker, og når brukeren fyrer av RegistrationRequested eventet ved å klikke på knappen vil controlleren ta over og gjennomføre registreringen.

Om du drar inn Registration-kontrollen i Default.aspx så kan du teste at det fungerer som det skal. Foreløpig får du tilbakemelding ved at knappen blir disablet og teksten sier “Success!”, men her kan man tenke seg at vi skjuler hele kontrollen og viser login-kontrollen (som fortsatt gjenstår å lage) i stedet.

Jeg har valgt å plassere repositorien i Application state – jeg vet ikke hvor bra dette fungerer i praksis, og det er ikke sånn jeg ville har gjort det “i virkeligheten”, men det fungerer greit her og nå. ASP.NET og state er ikke det viktige temaet i denne artikkelen, så ikke gi meg flak for denne fremgangsmåten. Initaliseringen skjer i Global.asax:

Innlogging

For å implementere innlogging går jeg frem som jeg gjorde da jeg startet på brukerregistrering. Innlogging er et eget ansvar som trenger egne tester, eget view og egen controller. Controlleren vil bruke UserRepository, som man gjennom testene må utvide med logikk for å hente opp en bruker basert på navn. Den vil også gjenbruke PasswordHashService, fordi passordet må hashes før man kan sammenligne med det lagrede passordet.

Gjennom denne blogposten har du allerede sett og lært alt du trenger for å fullføre oppgaven, så jeg stopper her. Om du har lyst til å øve deg litt selv så anbefaler jeg at du fortsetter på egenhånd. Skriv tester først, og ikke lag en eneste klasse eller metode før du har kode (test eller annen kode) som allerede refererer klassen/metoden.

Jeg håper du likte denne TDD-tutorialen. I en ny blogpost som kommer veldig snart vil jeg analysere designet jeg har kommet opp med, og snakke litt om best practises rundt smidig arkitektur. På gjensyn!

Knagger: Asp.Net, CodeRush, Db4objects, DRY, Mocking, Moq, NUnit, Phil Haack, Repository, TDD, Utenfra-og-inn

Robert C. Martins Clean Code: A Handbook of Agile Software Craftsmanship er en viktig og spennende bok. Mange mener mye om hva ren kode er for noe, men det har vært vanskelig å finne konkrete og komplette kilder. Her har Uncle Bob samlet og forklart motivasjonen bak et godt sett med regler for hvordan man skriver kode med høy kvalitet i de små detaljene.

Så hvorfor skal vi skrive ren kode? Er det ikke nok at programvaren gjør det den skal? Jo, kanskje, hvis det er 100% bugfritt, og aldri skal endres på noen som helst måte. Og hvor sansynlig er det? Ufattelig mye energi brukes på å forstå og navigere i dårlig skrevet kode, og utviklingsteam som jobber i slike systemer er langt fra så effektive som de kunne ha vært. Ren kode kan endre dette ganske drastisk.

Boken har tre deler: Første del beskriver prinsipper og praksiser for å skrive kode som kommuniserer godt, og argumenterer for hvorfor en profesjonell utvikler skriver ren kode. Andre del inneholder en rekke studier av eksisterende kode, som Uncle Bob fikser på for å gjøre den bedre. Og siste del er mer eller mindre en liste over “regler” som ren kode ifølge forfatteren skal følge.

Clean Code er en bok som fungerer både for ferske og erfarne utviklere. Folk med flere års erfaring vil tenke at de kjenner alle disse prinsippene fra før, men min erfaring tilsier at de fleset av oss ikke følger så mange av dem likevel. Alle har godt av å minnes på hva ren kode er for noe, og hvor viktig det er – og tradisjonelt har det vært alt for lite fokus på dette i bransjen. Får du hele teamet ditt til å lese boken, og så følge prinsippene i den, vil kvaliteten på det dere produserer garantert øke, noe dere vil nyte godt av i hele levetiden til produktet/produktene.

Uncle Bob advarer at boken er krevende, men jeg synes i grunnen den var ganske lettlest. Den inneholder ganske mye kode, men det leser vi jo hver dag likevel. Han har derimot rett i at det vil kreve noe av deg å lære deg å følge prinsippene i boken – det holder ikke bare å lese den, for så å gjøre som du vanligvis gjør. Du må øve på disse tingene, og praktisere dem hver dag.

Boken vil ikke lære deg alt det du trenger for å lage bra software – langt der i fra – men er en fin liten byggekloss på veien til å bli en Drivende Dyktig Utvikler. Jeg ble litt skuffet over noen av de refaktureringene Bob gjorde i del 2, jeg tror koden kunne ha blitt enda renere. Men jeg anbefaler gjerne denne boken likevel!

PS: Kodeekksemplene i boken er hentet fra Java, men det bør ikke være noe problem for en seriøs utvikler, samme hvilket språk du jobber i til vanlig – og spesielt ikke om du er en C#-utvikler som meg. Prinsippene Uncle Bob presenterer er universelle.

Knagger: Agile, Craftsmanship, Java, Robert C. Martin

Decorator pattern er et objektorientert designmønster som lar deg legge ny funksjonalitet til et eksisterende objekt uten å modifisere det. Funksjonalitet implementert som decorators kan “plugges inn” dynamisk når man måtte ønske det, og holder grunn-klassen fri for forstyrrende kode.

I denne artikkelen illustrerer jeg et tenkt tilfelle hvor vi blir bedt om å legge til ny funksjonalitet i et eksisterende system, og hvor vi kan velge å gjøre det enkelt – noe som kan føre til større problemer på sikt – eller vi kan velge å bruke decorators, som vil la oss beholde en ren og fleksibel løsning. Jeg viser hvordan jeg dekorerer den eksisterende klassen med ny funkjonalitet, og snakker til slutt litt om motivasjonen for å gjøre det på denne måten.

I det tenkte systemet vårt har vi et abstrakt begrep vi kaller for en Service. Du kan tenke på det som en typisk windows service. For å administrere en service har vi laget en klasse vi kaller ServiceRunner – den har metoder for å starte, stoppe, pause og re-starte en service.

ServiceRunner skjuler brukerne av koden vår for alle detaljene som inngår i de fire vanlige operasjonene vi ønsker å tilby. Implementasjonen ev Start() er vist over. Den er ikke spesielt kompleks, men det kunne tenkes at Service hadde et grensesnitt som det var vanskeligere å forholde seg til, og du aner ingenting om hva som skjuler seg bak de andre metodene – koden der kan godt være mere innviklet.

Systemet vårt fungerer ypperlig. Servicer starter og stopper mer eller mindre som de skal. Men så får vi inn et nytt krav fra kunden: Systemet skal logge hver gang en service starter, stopper, pauses eller re-startes.

Ok, det var jo ikke så vanskelig. Vi har allerede laget et abstrakt konsept vi har kalt Logger, som i praksis kan skrive til event-loggen, databasen, en logfil o.l. Vi kunne latt koden som kalte de ulike metoden på ServiceRunner logge før kallene, men hvordan skulle vi håndheve det? Nye klienter av ServiceRunner kan komme til, og da måtte vi ha duplisert kallene til Logger. Nei, vi kan gjøre noe mye enklere, Vi kan gi ServiceRunner tilgang til en Logger (gjennom dependency injection selvsagt), og implementere logging i hver av de fire metodene – illustrert her ved logging av Start i linje 12 nedenfor:

Supert, dette fungerte som en drøm. Vi måtte riktignok endre alle steder ServiceRunner opprettes (vi burde ha innført en factory, slik at det kun var et sted konstruktøren til ServiceRunner ble kalt), men det var en smal sak. Nå vil alle operasjoner på en Service bli logget.

Like etter at vi releaser den nye ServiceRunneren får vi inn et nytt ønske. Brukere av systemet har ulike rettigheter, og ikke alle har lov til å starte en gitt service, stoppe en gitt service etc. Ok, vi bestemmer oss for å bruke mer eller mindre samme teknikk; vi implementerer et ServiceAuthorization objekt som vi kan spørre om den påloggede brukeren har lov til å foreta bestemte operasjoner på servicen. ServiceAuthorization sendes inn i konstruktøren, og brukes i hver av metodene, som i linje 15 nedenfor:

Ser dere hva som skjer her? En veldig enkel klasse begynner å vokse etterhvert som vi trenger mer funksjonalitet. Denne naive måten å legge til adferd på fører til prosedyrebasert kode som blir vanskeligere og vanskeligere å holde orden på. Klassen får flere og flere dependencies til andre deler av systemet. Dette er begynnelsen på noe som om kort tid vil bli omtalt som et legacy-system av utviklerne som må vedlikeholde det.

Problemet er at vi må endre ServiceRunner hver gang vi skal legge til noe nytt som har med kjøring av servicer å gjøre. Vi bryter dermed med Open/Closed-prinsippet innenfor objektorientert design. Det er også vanskelig å argumentere for at ServiceRunner tilfredstiller Single Responsibility Principle – om vi vil endre hva vi logger så må vi endre ServiceRunner, om vi vil endre autorisasjonsprosessen må vi endre ServiceRunner, og om måten en Service fungerer på endres må vi også endre ServiceRunner.

Decorator Pattern

Decorator pattern er en alternativ løsning vi kan bruke for å implementere den nødvendige loggingen, autoriseringen, og en rekke andre, nye krav som måtte komme til. Første steg er å bruke ReSharper, Refactor! Pro eller manuell refakturering til å trekke ut interfacet fra den konkrete ServiceRunner-klassen. Dette vil gjøre det enklere å implementere dekoratørene.

Jeg velger å gi interfacet navnet ServiceRunner, mens jeg endrer den konkrete implementasjonen til å hete ServiceRunnerImplementor (alternativt kan du kalle interfacet for IServiceRunner og den konkrete klassen for ServiceRunner – en konvensjon du sikkert er mer komfortabel med). Med min metode behøver vi ikke endre alle eksisterende referanser til ServiceRunner – de vil nå referere interfacet, som er det vi ønsker.

Jeg har også bestemt at ServiceRunner skal ha en Service property som eksponerer instansen gitt gjennom konstructøren. Grunnen vil bli åpenbar om litt.

Steg 2 er å lage en abstrakt klasse som arver fra ServiceRunner: ServiceRunnerDecorator. Dette blir baseklassen for alle de ulike funksjonene vi vil dekorere ServiceRunner med. ServiceRunnerDecorator tar inn en instans av en ServiceRunner i konstruktøren, og delegerer så alle kall til denne instansen. Den abstrakte dekoratøren er altså ikke annet enn en enkel wrapper rundt en ServiceRunner.

Og nå kan vi implementere logge-funksjonaliteten. Vi lager er konkret ServiceRunnerDecorator som vi kaller for LoggingServiceRunner. I tillegg til å ta inn en instans av en ServiceRunner trenger den selvsagt også en Logger. I Start-metoden kan vi gjøre loggingen på samme måte som vi tidligere gjorde i den orginale ServiceRunner’en. Deretter delegeres resten av start-logikken til baseklassen, som til syvende og sist kaller Start-metoden på den orginale klassen.

Nå ser du også grunnen til at jeg ønsket en Service property i ServiceRunner, slik at dekoratørene kan få tak Servicen de skal gjøre noe med (i dette tilfelle logges navnet).

Videre kan vi implementere en ny dekoratør som tar seg av å sjekke om brukeren har lov til å bruke tjenesten. Jeg kaller den StrictServiceRunner:

Som du ser har hver av klassene vi nå står igjen med hvert sitt ansvar: StrictServiceRunner handler kun om autorisasjon, LoggingServiceRunner handler kun om logging, ServiceRunnerImplementor bryr seg kun om å utføre de nødvendige operasjonene på Service-instansen. Hver av disse klassene kan så komponeres sammen, slik at når brukeren kaller Start() på sin instans av ServiceRunner så kalles Start-metoden etter tur i alle klassene, som nå utgjør en “pipeline” med relatert funksjonalitet. Du kan se for deg hvordan dekoratørene pakker inn den orginale ServiceRunner’en lag for lag, som en løk:

Nå bør vi til slutt implementere en factory for å opprette ServiceRunnere, slik som jeg hintet til helt i starten. Gitt en Service kan vi komponere en ServiceRunner med ønsket funksjonalitet (eller “dekor” om du vil).

Eller vi kan går for en mer dynamisk factory som komponerer ServiceRunnere basert på konfigurasjon, slik som dette:

Legg merke til hvordan jeg her potensielt legger til to LoggingServiceRunnere, en for logging til eventloggen i linje 9, og en for logging til databasen i linje 12.

Når skal man bruke decorators?

I Working Effectively with Legacy Code (kapittel 6: “I Don’t Have Much Time and I Have to Change It”) snakker Michael Feathers om hvordan Decorator pattern kan være et nyttig hjelpemiddel når man skal implementere ny funksjonalitet i et komplisert system man ikke er trygg på. La oss tenke oss at den orginale ServiceRunner-klassen er mye større, og allerede har mange avhengigheter som gjør det svært vanskelig å lage enhetstester for den. Vi ønsker å være trygg på den nye funksjonaliteten vi skal implementere, og vil derfor skrive tester, men det koster rett og slett for mye å få ServiceRunner inn i et testing harness.

Da kan man velge å implementere den nye funksjonaliteten som en dekoratør. Den kan testes uavhengig av ServiceRunner. ServiceRunner er i seg selv fortsatt Legacy Code, men alt nytt vi legger til er enhetstestet og til å stole på. Dette er ikke ønskedrømmen – aller helst burde vi klare å få testet ServiceRunner også – men noen ganger må man ta snarveier, og da er Decorator pattern et bra verktøy.

Robert C. Martin forteller også om Decorator i boken Agile Principles, Patterns, and Practices in C#, hvor han klassifiserer mønsteret sammen med Visitor pattern og Extension pattern. Han har følgende å si om hvordan disse teknikkene støtter opp under gode OO-prinsipper:

“The Visitor family of patterns provides us with a number of ways to modify the behaviour of a hierarchy of classes without having to change them. Thus, they help us maintain the Open/Closed Prinsiple. They also provide mechanisms for segregating various kinds of funktionality, keeping classes from getting cluttered with many different functions. As such, they help us maintain the Common Closure Prinsiple. It should be clear that LSP [Liskov's Substitution Principle] and DIP [Dependency Invertion Principle] are also applied to the structure of the Visitor family.”

Uncle Bob gir videre følgende råd om bruken av Visitor, Decorator og Extension:

“The Visitor patterns are seductive. It is easy to get carried away with them. Use them when they help, but maintain a healthy skepticism about their necessity. Often, something that can be solved with a Visitor can also be solved by something simpler.”

For mer informasjon anbefaler jeg at du tar en titt på Decorator Pattern på wikipedia, og så finner du en video kalt Learning the Decorator Pattern som er under 10 minutter lang på DimeCasts.NET.

Knagger: Agile Principles, Patterns, and Practices in C#, Dependency Injection, Dependency Invertion Principle, Open Closed principle, Michael Feathers, Legacy, Robert C. Martin, Single Responsibility Principle, SOLID

På flytoget etter NDC 2009 hadde mine kollegaer og jeg en nokså heftig diskusjon om bruk av null. Det var et nokså uskyldig spørsmål som startet det hele:

“Sjekker du alltid om parametrene som sendes inn til en metode er null, og kaster ArgumentNullException om så er tilfelle?”

Mitt svar var ganske bestemt: Nei, det gjør jeg stort sett aldri! For meg er det å sjekke for null noe man gjør i frykt, noe man gjør for å kompansere for dårlig kode. I de fleste tilfeller er det en bug å sende inn null, og jeg ønsker ikke å legge til rette for sloppy kode ved å sette på støttehjulene og teste for dette.

Kode som forventer en instans men får null vil kaste en NullReferenceException, som er mer enn godt nok for kode som er godt skrevet – den energien en eventuelt putter inn i å lage mer detaljerte feilmeldinger er ikke verdt det i dette tilfellet.

Videre hevdet jeg at null i seg selv er en uting. Kode som er skrevet slik at man gjentatte ganger må teste for null er ikke god kode. Å teste for null er en code smell. Bruk av null hører ikke hjemme i kode som befinner seg andre steder enn på det laveste abstraksjonsnivået – null er ikke noe forretningsfolk kan snakke om, og bør derfor etter min mening heller ikke eksistere i kode som beskriver forretningskonsepter.

Null Object pattern

Problemet jeg snakker om kan illustreres med følgende kodesnutt:

Siden databasen kan returnere null om “T-Man” ikke eksisterer benytter vi oss av det faktum at det første uttrykket i if-testen evalueres først, og det andre uttrykket kun om det første er sant. Vi har alle skrevet kode som dette her. Vi har også alle glemt å teste for null fra tid til annen – selv om dette er et vanlig mønster så er det både uelegant og noe som fører til mange feil.

I stedet for å returnere en null-referanse kunne vi la databasen kaste en exception, men da måtte vi ha brukt try/catch ved alle kall, noe som er enda mindre elegang.

Et alternativ til å bruke null-referanser er å implementere et objekt som har det forventede grensesnittet, men som ikke gjør noen ting. Dette kaller vi for Null Object. Min kollega hevdet at dette er veldig tungvindt å implementere, men etter å ha tenkt meg litt om så finner jeg mange steder hvor jeg har brukt det selv, og hvor det er langt fra vanskelig å implementere, samtidig som det gjør koden som bruker objektene langt enklere.

Her er et eksempel fra prosjektet jeg holder på med akkurat nå. Brukeren skriver inn noe tekst som blir gjort om til en UserCommand. Poenget er å unngå å returnere null, så hvis teksten som sendes inn er gibberish så returnerer jeg en UnknownCommand:

UnknownCommand er et null-objekt: Det implementerer UserCommand-interfacet, men gjør ingen ting. Klienter av UserCommand kan bruke dette objektet på samme måte som alle andre commands – jeg trenger ikke kaste noen exceptions, og aldri teste for null.

Jeg har flere eksempler som ligner på dette. Der hvor jeg bruker strategy pattern i kombinasjon med en eller annen form for en factory, implementerer jeg nesten alltid også et null-objekt, en dummy-klasse som kan brukes i stedet for en virkelig strategi.

Dette beviser ikke at null objects kan brukes over alt, ei heller at det er trivielt, men jeg er ganske sikker på at bruk av dette mønsteret vil føre til kode som er enklere å lese og vedlikeholde, og som er mer feilfri.

Kan vi erstatte != null testen?

Men det er ikke til å komme bort ifra at man av og til må bruke null-referanser. Det er også et faktum at jeg hater å skrive != og == null. Jeg ønsker derfor en mer deskriptiv måte å teste på – en som ikke bryter abstraksjonsnivået. Dette er hva jeg har kommet frem til:

Denne testen feiler ikke! Men hvordan er det mulig å kalle en metode på en null-referanse? Jo, det er mulig takket være extension methods:

Er det ikke vakkert?

Finite state machines (FSM), tilstandsmaskiner på norsk, er blant de mest kraftige abstraksjonene vi programmerere har tilgjengelig, og har et stort og variert bruksområde. FSM gir oss en enkel og elegant måte å utforske og definere oppførselen til komplekse systemer, og implementasjonen er både enkel å fortså og enkel å modifisere. I boken sin Agile Principles, Patterns, and Practises in C# sier Robert C. Martin følgende om dette:

“Finite state machines are underutilized. In many scenarios their use would help to create cleaner, simpler, more flexible, and more accurate code.”

I den enkleste formen er en state machine gjerne implementert som en eller flere switch/case statements – i mer komplekse løsninger kan man bruke STATE pattern. I .NET 3.0 fikk vi også Windows Workflow Foundation, hvor vi kan designe State Machine Workflows.

Men alle disse alternativene er mere komplekse enn å lage en FSM basert på en overgangstabell. I denne artikkelen designer jeg en generisk FSM-motor som kan gjenbrukes i mange scenarier. For å illustrere hvordan den virker vil jeg implementere tilstandsmaskinen som finnes i en typisk passeringsautomat – slike som man finner på T-banestasjoner, flytoget osv.

I diagrammet under ser du tilstandene (states), overgangene (transitions), hendelsene som kan inntreffe (transition conditions) og det systemet skal utføre når det går fra en tilstand til en annen (actions) i en slik passeringsautomat.

Ta for eksempel en automat som i utgangspunktet er låst. Hvis noen putter en mynt på automaten, vil systemet kalle en rutine for å låse opp porten, og endre statusen til å være ulåst. Når den så registrerer at noen passerer porten, vil den kalle rutinen for å låse porten, og returnere til den låste tilstanden. Hvis noen passerer mens systemet er i låst tilstand, vil automaten kalle alarm-rutinen og forbli i låst tilstand.

Skulle noen finne på å putte på penger mens systemet er ulåst, vil automaten si “tusen takk”, og forbli i ulåst tilstand.

Det første jeg vil gjøre er å opprette et par enumerasjoner som beskriver systemets tilstander og hendelser:

Jeg utviklet selvsagt automaten vha. TDD, og her følger oppsettet av testklassen, som viser hvordan en StateMashine opprettes og konfigureres:

Legg merke til det spesielle using direktivet på linje 9. Dette er ikke et krav, men lar meg definere en StateMachine-variabel på linje 14 og initiere den på linje 29 uten å spesifisere hvilke enumerasjoner som skal brukes. Dette er et generelt tips om hvordan man kan gjøre kode som bruker mye generics mer lesbar.

Linje 16 til 24 setter opp fire dummy-actions som skal brukes når jeg tester tilstandsmaskinen. Det mest interessante kommer først på linje 32, hvor jeg begynner å definere tilstandsovergangene.

Du kan lese linje 32 på følgende måte: Hvis nåværende tilstand er LOCKED, og noen putter på en COIN, så skal tilstanden endres til UNLOCKED, og “unlock” skal kjøres.

Den første testen jeg trenger sjekker bare den initielle tilstanden, som jeg satte i konstruktøren. Testen er ikke mer enn én linje:

Deretter skriver jeg tester for hver av de fire mulige overgangene. I hver test setter jeg først gjeldende status, noe som bare er aktuelt i enhetstestene – i virkelig bruk vil man ikke overstyre status på den måten. Deretter sender jeg inn et event til tilstandsmaskinen, før jeg sjekker ny status og om riktig action har blitt kalt (ref oppsettet av test-klassen). Her er testene:

Nå bør du skjønne hvordan StateMachine skal brukes, og jeg er klar for å vise hvordan den er implementert. Her er første bit; StateMachine har en generisk definisjon som forventer to typer som skal representere henholdsvis statuser og eventer: Jeg har kalt dem TState og TEvent. Construktøren tar inn initiell status:

Videre inneholder klassen en liste med overganger (linje 21). En overgang – Transition – er en intern klasse i StateMachine (linje 23). Det er ikke så ofte jeg bruker private klasser i andre klasser, men her passet det fint. AddTransition-metoden (linje 31) som jeg brukte i SetUp i testklassen oppretter en ny Transition og legger den til i listen.

Og da gjenstår bare HandleEvent-metoden, som er gjengitt nedenfor. Den finner riktig overgang basert på event-parameteren og gjenldende status. Til dette bruker jeg Find-metoden til List. Hvis en overgang finnes, brukes den til å sette ny status, og riktig action kalles (linje 55 og 56).

Hvis et ugyldig event sendes inn for gitt status (ikke mulig for denne passeringsautomaten, men kan tenkes for andre tilstandsmaskiner), så kaster jeg et ArgumentException.

Min StateMachine er en forbedring av Robert C. Martins Transition Tables-eksempel fra boken jeg refererte. Ved å bruke generics har jeg gjort den gjenbrukbar. Når du trenger en tilstandsmaskin behøver du bare definere tilstandene og eventene, og konfigurere StateMachine med de riktige overgangene.

Det er også verdt å merke seg at du ikke er begrenset til å bruke enumerasjoner til å definere tilstander og/eller eventer; du kan like gjenre bruke klasser, slik som jeg har gjort her:

Den abstrakte klassen TurnstileState (turnstile er engelsk for passeringsautomat) definerer et interface (et tomt et sådan) for en tilstand. LockedState og UnlockedState arver fra TurnstileState, og erstatter Event.LOCKED og Event.UNLOCKED. Jeg har overstyrt Equals fordi HandleEvent bruker Equals til å finne riktig overgang (merk at man også alltid skal overstyre GetHashCode når man overstyrer Equals).

Flytende konfigurering..

Til slutt gjorde jeg en liten forbedring i hvordan jeg oppretter overgangene. Flytende interfacer er veldig populært for tiden, og kan gjøre kode mer lesbar. Sammenlign SetUp-metoden nedenfor med den jeg presenterte tidligere, og se om du er enig i at dette er bedre.

Da jeg implementerte det som trengtes for å få denne setup-metoden til å kjøre oppdaget jeg noe ganske morsomt. Konfigurerings-objektet jeg opprettet er faktisk en tilstandmaskin – en Finite State Machine. Begynner du først å tenke på denne måten så oppdager du stadig nye tilfeller hvor FSM-teknikken kan benyttes.

Tilstandsmaskiner kan gjøre koden din enklere å forstå, vedlikeholde og endre, og bør ikke undervurderes. De fjerner “spagetti”, og lar dine øvrige klasser konsentrere seg om sine primære ansvar. Tenk gjennom hvilke tilstander koden din kan ha neste gang du programmerer, og vurder å bruk en tilstandsmaskin for å forenkle koden.

Knagger: Fluent, Patterns, Robert C. Martin

Robert C. Martin’s Agile Principles, Patterns, and Practices in C# er DEN BESTE programmeringsboken jeg noen gang har lest!!!

Det er ikke så ofte man kan begynne en blogpost med en setning som det der, og bruke både all-CAPS og tre utropstegn uten å få en flau smak i munnen. Men denne boken fortjener det virkelig. Den gir deg både lyst og kunnskapen du behøver for å omforme deg selv til en ideell, smidig systemutvikler.

Boken er full av anekdoter som virkelig får deg til å fortså hva som er galt med mange prosesser i dag, og hva som kan gjøres bedre. Og den utgjør bortimot et komplett sett med teknologi-uavhengig kunnskap om hvordan du skal gå fra en diffus problemstilling til et fungerende produkt.

Section I: Agile development

Den første delen av boken handler om smidig utvikling. Bob presenterer hovedtrekkene i eXtreme Programming, og går spesielt i dybden på planlgging, testing og refakturering. Han presenterer også en veldig bra historie som viser hvordan parprogrammering kan fungere i praksis:

“In order to demonstrate XP practices, Bob Koss and Bob Martin will pair program a simple application while you watch like a fly on the wall. We will use test first design and a lot of refactoring to create our application. What follows is a faithful re-enactment of a programming episode that the two Bob’s actually did.”

Historien er også tilgjengelig online, riktignok implementert med Java-kode – du kan lese den her.

Section II: Agile design

Her begynner boken virkelig å ta av. Bob snakker først om hvorfor design “rotner” over tid, og bruker resten av del 2 til å forklare hvordan man skal unngå at dette skjer. Han går i dybden på en rekke prinsipper innen objektorientert design, de såkalte SOLID prinsippene, og selv om jeg hadde hørt og lest en god del om dem fra før var det først med denne boken at jeg virkelig begynte å forstå.

Han forklarer hvorfor prinsippene er viktige, hvordan man skal kode for å innfri dem, og ikke minst hvilken tradeoff det innebærer å følge dem. Dette siste inpirerte meg til å skrive en liten blogpost jeg kalte når skal man følge SOLID prinsippene.

Bob bruker også mye av del 2 til å snakke om UML, og bruk av design-diagrammer innenfor smidig utvikling. Mange er av den oppfatning at modellering er noe man ikke skal gjøre når man er agile, men det kan være både feil og farlig. Bob lærer deg all den UML’en som er nødvendig for en smidig utvikler, og mener mye om hvordan man skal bruke dette “verktøyet”.

Section III: The Payroll case study

I del 3 demonstrerer Bob hvordan man går fra noen diffuse krav til et komplett program. Han bruker TDD, og viser deg all koden han produserer – inkludert testene. Han forteller grundig hvordan han tenker, og vi får se hvordan han følger OO-prinsippene og hvordan koden utvikler seg over tid.

I denne delen presenteres et hav av design patterns / mønstre, den mest forståelige forklaringen av design patterns jeg har vært borti faktisk, og vi lærer hvordan de brukes for å tilfredstille de grunnleggende prinsipene. Med fare for at den som leser boken blir pattern happy lærer han bort Command, Template Method, Strategy, Adapter, Monostate, Null object, Visitor, Decorator, Gateway, Proxy, State, osv., osv.

Denne delen av boken inspirerte meg til å skrive om hvordan man bryter avhengigheter mellom klasser, hvor jeg benyttet Strategy og Adapter.

Section IV: Packaging the Payroll System

I del 4 fortsetter man med applikasjonen fra del 3. Bob forteller oss om hvordan man bryter opp et prosjekt i moduler basert på Cohesion og Coupling. Han presenterer flere prinsipper, og patterns for å understøtte disse prinsippene. Og han fortsetter å presentere enhetstester og kode.

Denne delen inpirerte meg til å kode og blogge om hvordan man kan bruke en tilstandsmaskin til å gjøre kode mer presis og fleksibel: En generisk state machine i C#.

Mot slutten implementerer han også et grafisk brukergrensesnitt, og bruker da WinForms og Model View Presenter-mønsteret (MVP). Dette er det grundigste og mest forståelige eksempelet på MVP jeg noen gang har sett.

Det kan tenkes at jeg leste denne boken på akkurat det riktige tidspunktet i min egen utvikling, og at den ikke vil passe like godt for alle. Jeg tør likevel å anbefale den på det sterkeste til alle utviklere som ikke allerede praktiserer best practices innen smidig utvikling (TDD, parprogrammering, etc.) og som ikke allerede er guruer innen objektorientert design og vedlikeholdbar kode.

Andre Uncle Bob-relaterte blogposter: En karriære innen programmering | For mange utviklere som ikke bryr seg

Object Thinking er en bok skrevet av forfatter Dr. David West i 2004. Den er overraskende nok utgitt av Microsoft, men hører egentlig hjemme i eXtreme programming / Domain-Driven Design / Smalltalk-universet, og har potensiale til å totalt endre ditt syn på softwareutvikling.

Dette er en historiebok om utviklingen innen programmeringsspråk. Det er også en politisk diskusjon, og ikke minst et filosofisk studie av hva programmering er, og hvordan det bør gjøres. Hovedtemaet er objektorientering, og forfatteren hevder at på tross av at mange sier at de driver med OO, så gjør de langt fra akkurat det. Han sier at vi har misforstått, eller eventuelt glemt, bakgrunnen for objektorientering. For å få til alt det som OO gjør tilgjengelig for oss så må vi tenke objekter på den riktige måten.

Nesten med en gang jeg startet å lese merket jeg at boken provoserte meg. Den grep tak i noen av mine fundamentale oppfatninger – ikke bare rundt programmering, men i verden generelt – og snudde dem på hodet. Og så merket jeg hvordan teksten begynte å forandre mine egne meninger…!

Det var faktisk ganske skummelt. Men også veldig spennende. Noe av det mest besynderlige var hvordan han klarte å introdusere meg til smidig utviklingsfilosofi på en helt ny måte. Han presenterer en lang avhandling om den skarpe kontrasten mellom Formalisme og Hermeneutikk.

Formalisme er sterkt knyttet til rasjonalisme, et mekanisk og deterministisk verdensbilde. Her følge man formelle metoder og teknikker. Hermeneutikk i den motsatte enden av skalaen er et ikke-deterministisk verdensbilde, og i følge Dr. West i samsvar med ting som eXtreme programming og objekt-tenking. TDD er for eksempel et glimrende eksempel på ikke-formalisme. TDD er en praktisk metode som det viser seg kan gi et veldig bra resultat, uten at det kan bevises rasjonelt.

Desverre, sier han, er det få XP/agile-praktikanter som er klar over dette filosofiske skillet. Og han har helt rett; selv har jeg blitt presentert smidig utvikling i veldig formelle rammer, og det er først nå, etter å ha lest Object Thinking, at jeg begynner å forstå det jeg tidligere bare glimtvis har sett – at smidig utvikling helt grunnleggende er en annen filosofi enn det som råder i softwarebransjen i dag.

Ken Auer sier det slik:

“Too many software professionals who use object-oriented tools aren’t object thinkers. Every developer Dave West reaches with this book takes us a step closer to improving software – and the industry.”

Jeg merker at det er vanskelig, eller snarere umulig, å formidle denne oppdagelsen på en god måte. Jeg tror dette er en oppdagelse hver og en må gjøre i sitt eget tempo. La meg i stedet fortelle litt mer om boken..

Objekt-tenking går rett og slett ut på å tenke som et objekt. Tradisjonelle utviklere tenker som datamaskiner. De konsentrerer seg om den tekniske løsningen, om implementasjon. OO-programmerere må lære seg å tenke mer som objekter – vi må tenke på problemet, og modellere det i stedet.

Nøkkelordet fra boken for meg er Behaviour – adferd! Vi må designe programvaren vår rundt objekter, som igjen er definert i form av adferd. Dette i sterk kontrast til den data-sentriske modelleringen de fleste normalt bedriver. Rockford Lhotka, utvikleren bak CSLA.NET, anbefaler også Object Thinking, og sier det på denne måten:

“To me that’s the value in West’s book. The philosophy of each object having a single, clear responsibility. Of objects collaborating with other objects to perform complex tasks, without being complex themselves.”

Den andre delen av boken..

Object Thinking har også en praktisk del. Mens den første halvdelen fokuserer på historie, filosofi, og hvordan man skal tenke, presenterer Dr. West i den andre halvdelen en del teknikker – modelleringsteknikker – som er i samsvar med objekt-tenking. Dette falt ikke så godt i smak for meg. Jeg vil foreslå at man hopper over noen av de mest praktiske delene, og i stedet leser noe sånt som Agile Principles, Patterns, and Practices in C# av Robert C. Martin, som har en litt annen tilnærming som er mer kjent for meg, men som fortsatt er i samsvar med det Dr. West sier.

Til slutt et par linker: Boken kan du selvsagt få tak i hos Amazon. Det finnes også et intervju med Dr. West på PolymorphicPodcast.

Knagger: Agile, DDD, eXtreme programming, Objektorientering, Smidig

Tette koblinger er noe man snakker mye om innen utvikling av software – noe man bør unngå bl.a. fordi det gjør programmene vanskeligere å endre. Og at det vil komme endringer er det eneste sikre i ethvert softwareprosjekt.

I denne artikkelen forsøker jeg å illustrere et helt vanlig scenario med tett kobling mellom to klasser. Jeg snakker litt om hva to av SOLID-prinsippene sier om dette, og viser hvordan avhengighetene kan løses opp ved å benytte et par velkjente design patterns.

I dette fiktive eksempelet skal jeg implementere en del av programvaren til en mobiltelefon. Man må kunne taste inn et telefonnummer, og når nummeret er tastet skal telefonen ringe opp nummeret. Jeg ser da for meg at jeg behøver en klasse for å representere en knapp: Button. Når en knapp blir trykket på, sender den avgårde sifferet knappen representerer til en annen klasse som skal ringe nummeret; jeg kaller denne klassen for Dialer.

Disse to klassene danner et typisk klient-tjener forhold: Button bruker Dialer som en tjeneste, og har en sterk knytning og avhengighet til den, f.eks. ved at den holder en referanse til et Dialer objekt, slik som dette:

Denne harde koblingen er lite fleksibel, og fører til kode som er vanskelig å endre eller utvide. Det finnes flere prinsipper innen objektorientering som kan brukes til å identifisere problemet. Ta for eksempel dette:

Om du ikke kjenner til OCP fra før er det ikke helt lett å skjønne hva man mener med “åpen for utvidelse men lukket for endringer”. Men se på Button-klassen. Den er som sagt hardt knyttet til Dialer, og skulle vi ønske å benytte en annen dialer, så må vi endre Button. Butten er altså ikke åpen for denne typen utvidelser.

Et annet prinsipp som sier noe om hva vi kan gjøre med dette er DIP:

For å gjøre noe med dette kan vi bruke det vi kaller for STRATEGY PATTERN – vi definerer et interface som Button kan være avhengig av istedet. Mange ville f.eks. opprettet et IDialer interface, slik som dette:

Nå kan man utvide med flere typer Dialers uten at man må endre Button-klassen. Men.., det er noe som skurrer litt. Button føles fortsatt for hardt knyttet mot dette Dialer-konseptet. Det kan jo godt tenkes knapper skal benyttes til helt andre ting enn å ringe (som å sende SMS, spille spill o.l.).

Løsningen er enkel men genial. Interfacer har nemlig mye mer med klienten i avhengighetsforholdet å gjøre (i dette eksempelet Button) enn med klassene som implementerer dem (Dialer). En Dialer er noe som er interessert i å få vite når en knapp blir trykket på. Hvis vi lar Button eie interfacet ved å døpe det om til å hete noe sånt som IButtonListener, og lar Dialer implementere dette, så åpner vi opp for å lage andre klasser som også kan lytte til knappetrykk – uten at de har noe med det å ringe å gjøre – og det uten at vi må modifisere hvordan knappen er implementert.

Nå er Button helt uavhengig av alt som har med Dialer å gjøre, selv om den under kjøring av programmet vil motta en referanse til et Dialer-objekt. Og fra knappens ståsted virker dette veldig fornuftig.

Dialer derimot er avhengig av å implementere IButtonListener. Vil vi ta løsningen vår et steg videre kan vi fjerne denne avhengigheten også. For å gjøre det kan vi bruke et annet mønster som kalles ADAPTER PATTERN. Det bruker man bl.a. om man vil skjule/konvertere et interface, f.eks. om man ikke har mulighet til å endre en klasse som Dialer, eller som i dette tilfellet når man ikke ønsker å rote til Dialer med referanser til Button-konseptet.

Vi oppretter da en ButtonDialerAdapter-klasse. Denne adapteren lar vi arve fra IButtonListener, og det er den klassen Button nå vil få en instans av under kjøring. ButtonDialerAdapter vil i sin tur ha en referanse til Dialer, og oversetter knappetrykket til den korresponderende meldingen/funksjonskallet i Dialer.

Button har fortsatt bare en avhengighet mot IButtonListener, som gir fullstendig mening. Og Dialer har nå ingen avhengigheter mot noe som har med Button å gjøre. ButtonDialerAdapter avhenger av Dialer og IButtonListener. Ved å bruke strategy pattern og adapter pattern har vi tilfredstilt både Open/Close-prinsippet (OCP) og Dependendcy-Invertion (DIP).

OCP er på mange måter selve kjernen i objektorientert design. Ved å følge det kan man oppnå fleksibilitet, gjenbruk og vedlikeholdbar kode. Man sier også at å snu avhengighetene (DIP) er det som skiller objektorientert design fra prosedyre/transaksjonsbasert design.

Det er derimot ikke lurt å innføre abstraksjoner (interfacer og abstrakte klasser) over alt i koden. Utvikleren må passe på å bruke abstraksjoner de stedene i programmet som endres ofte. Robert C. Martin sier blant annet:

Confirming to OCP is expensive. It takes development time and effort to create the appropriate abstractions. These abstractions also increase the complexity of the software design. There is a limit to the amount of anstractions that the developers can afford. Clearly, we want to limit the application of OCP to changes that are likely.

Så hvordan bestemmer man seg for når man skal bruke prinsippene? Vi gjør nødvendige undersøkelser, vi stiller de nødvendige spørsmålene, og vi bruker vår erfaring og sunn fornuft. Og så venter vi til endringene inntreffer! Onkel Bob sier nemlig videre:

“Fool me once, shame on you. Fool me twice, shame on me.” This is a powerful attitude in software design. To keep from loading our software with needless complexity, we may permit ourselves to be fooled once. This means that we initially write our code expecting it not to change. When a change occurs, we implement the abstractions that protect us from future changes of that kind. In short, we take the first bullet and then make sure that we are protected from any more bullets coming from that particular gun.

Men jeg tror likevel man må øve på å bruke disse prinsippene om man skal se behovet når det dukker opp. Og man må også kunne overføre erfaring om endringer fra et utviklingsprosjekt til et annet. For flere synspunkter på akkurat dette kan du se kommentarene etter posten min om når man skal bruke SOLID prinsippene.

Les også: T-Man tipser om specification pattern

Denne artikkelen ble til under inspirasjon fra Robert C. Martins bok Agile Principles, Patterns, and Practices in C# (2006).

SOLID er benevnelsen på fem prisnipper innenfor objektorientert softwaredesign som vi har hørt mye om i løpet av den siste tiden. Blant annet holdt Mark Nijhof et innlegg på NNUG Bergen om SOLID i januar i år. Foredraget finnes også i blogpost-format her.

Siden det foredraget har jeg forsøkt å lære meg disse prinsippene, og brukt dem etter beste evne. Akkurat nå leser jeg Robert C. Martin’s Agile Prinsiples, Patterns, and Practices in C#, og da går det plutselig opp for meg at selv om mange har forsøkt å lære meg prinsippene, så er det ingen som sålangt har fortalt meg hvordan man skal bruke dem.

I boken sier Onkel Bob Martin at man skal bruke prinsippene når de trengs. Unødvendig bruk fører bare til unøvdendig kompleksitet. Jeg føler dette er et viktig poeng å få frem.

Ta for eksempel Single Responsibility Prinsiple (SRP). Dette prinsippet sier at en klasse kun skal ha ett ansvar, og ansvar defineres som én grunn til å endres. Men en grunn til å endres er kun en grunn til å endres om den endringen faktisk inntreffer. Onkel Bob sier at det er ikke lurt å innføre SRP – eller noe annet OO-prinsipp for den saks skyld – uten at man har symtomer som kan løses med prinsippet.

Dvs. at man ikke splitter opp en klasse i flere klasser basert på ansvarsområder før man får behov for å endre klassen. Når endringen kommer, og endringen kun gjelder for ett av ansvarsområdene, kan man bruke SRP og splitte ut det ansvarsområdet som endres til en ny klasse.

“Agile teams apply principles only to solve smells; they don’t apply principles when there are no smells. It would be a mistake to unconditionally confirm to a principle just because it is a principle. The principles are there to help us eliminate bad smells. They are not a perfume to be liberally scattered all over the system. Over-confirmance to the principles leads to the design smell of needless complexity.”

Knagger: Agile, SOLID, Robert C.+Martin, Pattern

Hver uke skriver jeg en artikkel for utviklerne i Contiki, hvor jeg forsøker å gi gode råd og tips først og fremst om ting som design og refakturering. Denne uken presenterte jeg Specification pattern, et mønster som isolerer business-regler og gjør kode som må ta mange avgjørelser enklere å lese og samtidig mere fleksibel.

Specification er et relativt avansert mønster som er en del av det som populært kalles Domenedrevet Design (DDD), som kan hjelpe oss (og da mener jeg spesielt oss i Contiki), til å eliminere duplisert kode. Jeg har alltid vært fasinert av konseptet om å lage en regelmotor, og dette mønsteret er én måte å implementere dette på.

Vi starter med litt tilfeldig kode..

For å fortelle deg om Specification vil jeg ta deg med på en liten reise, hvor vi starter med litt kode som har forbedringspotensiale, og som etterhvert vil endres til noe som er mer fleksibelt. Koden er ikke reell kode – bare noe jeg fant på i farten. SendIfPossible-metoden sender et dokument til en gitt bruker hvis noen kriterier tilfredstilles:

Desverre skriver de fleste av oss kode som dette fra tid til annen. Testene som gjøres her er vanskelige å lese, og reglene er vanskelige å forstå. Ok, la oss forsøke å forbedre dette litt da….

Trekk ut metoder

Vi har nå trukket ut inneholdet i de to if-uttrykkene til separate metoder. Dette er en vanlig refaktureringsteknikk som add-ins som ReSharper, Refactor! og til og med Visual Studio kan hjelpe deg med. Gjennom å gi metodene gode navn er det klarere hvilke kriterier som må møtes for at dokumentet skal sendes til brukeren:

Dokumentet må være visningsklart, dvs. at statusen ikke må være DRAFT, ikke RELEASECANDIDATE, og hvis godkjenning av dokumenter er påkrevd så kan statusen heller ikke være FINAL. Og så må sikkerhetsnivået være ok for den gitte brukeren, dvs. at dokumentet enten må være PUBLIC, eller i tilfeller hvor det er RESTRICTED så må brukeren enten ha TRUST LEVEL 3 eller høyere, eller vi må tjene 10.000 eller mer på denne personen.

Ok, så kanskje det ikke var så lett å lese og forstå likevel. Dette bør vi kanskje splitte opp mere.

Men før vi gjør det, la oss først tenke gjennom om noe av denne logikken skulle vært flyttet til dokumentet eller bruker-objektet. For eksempel kunne vi ha opprettet en metode på IDocument for å spørre dokumentet om det var visningsklart. Men da måtte vi ha gitt IDocument en dependency mot IConfiguration, som jo holder på ApprovalNeeded-informasjonen. Eller i alle fall sende inn denne informasjonene til dokumentet på en eller annen måte. Og dette er noe dokumentet ikke burde behøve å forholde seg til. Det samme gjelder for å sjekke sikkerhetsnivå basert på bruker, hvor man må kombinere informasjon fra dokument og bruker – i tillegg til noen hardkodede konstanter som absolutt burde vært isolert bedre.

Trekk ut flere metoder

Som du forhåpentlig vis ser blir koden mer lesevennlig jo mer vi splitter den opp, hovedsaklig fordi metodenavnene dokumenterer hva testene egentlig betyri domenemodellen vår. Men det gjenstår noen problemer. For det første begynner det å bli “trangt om plassen” i klassen vår – det blir rotete og uoversiktelig med mange, små metoder. For det andre er det svært sansynlig at testene som disse metodene våre utfører også vil være nyttige andre steder, sansynligvis i andre klasser. Jeg får derfor lyst til å trekke dem ut herfra…

Specification pattern (enkel variant)

Da er det endelig tid for å ta en titt på Specification mønsteret. Først trenger vi et enkelt interface:

Interfacet trenger bare én metode, og den kaller vi IsSatisfiedBy. Og nå kan vi implementere noen forretningsregler:

I konstruktørene tar spesifikasjonene inn sine eksterne avhengigheter – all den informasjonen de måtte behøve for å avgjøre om et hvilket som helst dokument tilfredstiller forretningsregelen spesifikasjonen implementerer. Nå har vi et sentralt sted, en klasse, hvor regelen er definert, og som kan brukes hvor som helst i koden vår.

Ok, la oss forsøke å bruke disse reglene da:

I denne versjonen av SendIfPossible-metoden lager vi først en liste av spesifikasjoner, og kontrollerer så hver av dem før vi sender dokumentet til brukeren. Dette er bare en måte å bruke spesifikasjoner på. Den faktiske listen kunne ha blitt konfigurert et annet sted, og for eksempel inneholdt ulike criterier i ulike situasjoner.

Komponerbare spesifikasjoner

La oss utvide konseptet noe. Vi ønsker nå å kunne kombinere ulike spesifikasjoner, og dermed lage nye, komponerte spesifikasjoner på et høyere nivå. La oss utvide ISpecification og i tillegg lage en abstrakt klasse om arver fra dette:

Her har vi lagt til tre operasjoner på spesifikasjon: And, Or og Not. Den abstrakte klassen implementerer disse, en implementasjoner som vil være gjeldene for alle konkrete forretningsregler vi implementerer. Den abstrakte klassen benytter tre nye klasser som vi også må definere:

Vi kan nå implementere våre forretningsregler ved å arve fra CompositeSpecifications. Jeg overlater dette som en oppgave til leseren.., i stedet hopper vi direkte til slutten og ser hvordan dette kan brukes:

Nå har vi laget et slags “fluent interface” (eller mer presist brukt method chaining), og vi kan dermed kjede sammen forretningsregler slik som i dette banale eksempelet: isDone.And(okSecurity). Fantasien din har nok allerede begynt å jobbe med eksempler som har mange flere forretningsregler. Og for å sjekke om kriteriene er oppfylt trenger vi bare kalle IsSatisfiedBy på den komponerte spesifikasjonen.

Dette mønsteret åpner opp mange, spennende muligheter. Koden vår kan forholde seg til det enkle ISpecification interfacet for å sjekke kriterier, uten å vite noe om hvordan disse kriteriene har blitt konstruert. Spesifikasjoner kan bli sendt fra sted til sted, og nye spesifikasjoner kan kjedes til på ulike steg i prosessen – samtidig som koden holdes ren og ryddig.

Knagger: Contiki, DDD, Generics, Pattern, Refakturering

Inspirasjonskilder: DDD:Specification pattern blog post av Casey Charlton, Specification pattern på Wikipedia