tirsdag 31. januar 2012 F# Funksjonell programmering OO Patterns
I del 1 og del 2 har du sett meg implementere Template Method pattern i C# – først i en tradisjonell, objektorientert variant, og så i en mere fleksibel variant inspirert av funksjonell programmering. Nå er det på tide å se hvordan det samme kan gjøre kun med funksjoner. Det er på tide å finne frem F#.
Først trenger vi selve templaten, eller algoritme-skjelettet om du vil. processLog er en funksjon som har fire andre funksjoner som parametre, og bruker disse til å prosessere loggfilen. En slik funksjon kalles en høyereordens funksjon.
10 let processLog init read processLine cleanup = 11 init() 12 for line in read() do 13 processLine line 14 cleanup()
Deretter oppretter jeg et par funksjoner for å finne og rapportere errors i loggfiler:
22 let errorInit() = printfn "Errors:" 23 24 let errorLineProcessor line = 25 let m = Regex("^(\\d{17})\\s(\\w+)\\s(.+)$").Match(line) 26 if m.Success then 27 if m.Groups.Item(2).Value = "ERROR" then 28 printfn "%s: %s" 29 (m.Groups.Item(1).Value) 30 (m.Groups.Item(3).Value)
Det neste jeg trenger er FTP-stegene. Nedenfor oppretter jeg en funksjon som tar som innput en URL og returnerer to funksjoner – en for Initialize-steget i algoritmen og en for Cleanup-steget. Disse to funksjonene er lexical closures, fordi de har tilgang til URL-variabelen (mer om dette mange andre steder i bloggen).
33 (* Evaluates to a tuple of two closures *) 34 let makeFtpSteps url = 35 let setup = fun () -> printfn "Fetching log file from %s" url 36 let teardown = fun () -> 37 printfn "Archiving local log copy..." 38 printfn "Deleting log file %s" url 39 (setup, teardown)
Så kan jeg bruke funksjone jeg nettopp laget til å opprette de to closure'ene:
42 let (ftpFetch, ftpCleanup) = 43 makeFtpSteps "ftp://foobar.com/logs/my.log"
Jeg har nå to forskjellige funksjoner som skal kalles i Initialize-steget i templaten: ftpFetch og errorInit. I del 1 løste jeg dette ved at FTP-initialiseringsmetoden kalte baseklassens Initialize. I del 2 løste jeg det ved å ha en builder-klasse som kunne kombinere flere Action-delegater. Nå befinner jeg meg derimot i et funksjonelt språk, og da er det ingen sak å slå sammen to funksjoner til én:
48 (* Using forward composition operator to compose two functions *) 49 let errorInitWithFtpFetch = ftpFetch >> errorInit
errorInitWithFtpFetch er nå en ny funksjon som først evaluerer ftpFetch og deretter evaluerer errorInit. Om ftpFetch hadde hatt parametre ville den nye funksjonen også hatt det. Om ftpFetch hadde returnert noe, ville dette blitt sendt inn som argumenter til errorInit. Og om errorInit hadde hatt en returverdi så hadde dette vært returverdien til den nye metoden.
Da gjenstår det bare å mocke lesing av fil:
55 (* Faking it as usual... *) 56 let read() = [ 57 "20120125180000000 DEBUG Tick!"; 58 "20120125180100000 DEBUG Tick!"; 59 "20120125180132112 ERROR Some error occurred"; 60 "20120125180133056 ERROR Some other error..."; 61 "20120125180200000 DEBUG Tick!"]
... og å kjøre selve programmet ved å kalle processLog-funksjonen med de riktige argumentene:
64 processLog 65 errorInitWithFtpFetch 66 read 67 errorLineProcessor 68 ftpCleanup
Output er identisk med løsningene fra del 1 og del 2.
Løsningen jeg har kommet opp med her er betydelig enklere enn det du har sett før – her har vi ingen klasser som pakker inn koden og bestemmer hva vi kan og ikke kan gjøre. Løsningen er ekstremt fleksibel, og vil la meg kombinere funksjoner akkurat slik jeg ønsker. Objektene har vist seg å være helt overflødige – dette fordi Template Method i objektorientert design egentlig er et forsøk på å gjøre det samme som higher-order funksjons allerede gjør mye bedre.
Det eneste det kan se ut som om jeg har mistet er det å ha en LogProcessor-instans/objekt som jeg kan sende rundt og eksekvere når jeg måtte ønske. Men det løser vi selvsagt også lett. Å pakke inn et funksjonskall i en ny funksjon uten parametre slik som jeg gjør her kalles thunking:
71 (* Creating a thunk *) 72 let logProcessor() = 73 processLog 74 errorInitWithFtpFetch 75 read 76 errorLineProcessor 77 ftpCleanup 78 79 (* Evaluating the thunk *) 80 logProcessor()
logProcessor er nå i prinsippet et objekt.
I del 4 vil jeg avslutte serien om Template Method ved å se på hvordan jeg kan bruke multippel arv til å gjøre en objektorientert implementasjon like fleksibel som som den løsningen du nå fikk se.