torsdag 2. februar 2012 Common Lisp OO Patterns
Du var kanskje ikke klar over det, men Common Lisp er et objektorientert språk. Det påstås faktisk at det har det kraftigste og mest fleksible objekt-systemet av alle språkene vi har, og gjennom å implementere Template Method pattern i Common Lisp håper jeg å gi deg en grei introduksjon til noen av språkets muligheter. Du vil også få se at multippel arv løser utfordringen jeg hadde med den klassiske implementasjonen i del 1.
Pass på at du har designet fra del 1 klart for deg når du ser på denne løsningen.. Og husk at parantesene ikke er farlige :D
(PS: Jeg ser bort fra diskusjonen om det faktisk er gyldig å kalle det jeg presenterer i denne serien for Template Method pattern – delta i debatten her.)
Først trenger jeg å lage selve templaten – noe som definerer skjelettet til algoritmen, men overlater detaljene til en konkret rapport-implementasjon. Templaten opprettes ikke i en klasse som i del 1 og del 2, men heller ikke som en høyereordens funksjon som jeg brukte i del 3. logReport er en prosedyre som tar et rapport-objekt som parameter, og typen av dette rapport-objektet vil avgjøre detaljene i loggfil-prosesseringen.
2 (defun log-report (report) 3 "A template for reporting from log files" 4 (log-report-init report) 5 (loop for line in (log-report-read report) 6 do (log-report-process-line report line)) 7 (log-report-cleanup report))
Når jeg i den tredje linjen sier (log-report-init report) så er det det samme som å kalle metoden log-report-init på objektet report. Det neste jeg skal gjøre er å opprette disse metodene. Jeg bruker en makro som heter DEFGENERIC – du kan gjerne se på det som om jeg bruker dem til å opprette abstrakte metoder, slik jeg gjorde i LogProcessor i del 1. Metodene henger derimot ikke direkte på en klasse – klasser i Common Lisp har bare properties, mens metodene defineres for seg:
10 (defgeneric log-report-init (report)) 11 (defgeneric log-report-read (report)) 12 (defgeneric log-report-process-line (report line)) 13 (defgeneric log-report-cleanup (report))
Så bruker jeg DEFMETHOD til å lage noen fornuftige default-implementasjoner av de abstrakte metodene. For initialisering og cleanup lager jeg bare noen tomme metoder, mens metoden som prosesserer en linje bare skriver den ut.
17 (defmethod log-report-init (report)) 18 (defmethod log-report-process-line (report line) 19 (format t "~a~%" line)) 20 (defmethod log-report-cleanup (report))
Jeg kan også lage en konkret variante av metoden som leser en fil, og jeg mocker fillesingen slik jeg har gjort i de andre delene i denne bloggserien:
28 ; Faking reading the file as usual.. 29 (defmethod log-report-read (report) 30 (list "20120125180000000 DEBUG Tick!" 31 "20120125180100000 DEBUG Tick!" 32 "20120125180132112 ERROR Some error occurred" 33 "20120125180133056 ERROR Some other error..." 34 "20120125180200000 DEBUG Tick!"))
Nå kunne jeg ha kjørt koden ved å skrive for eksempel (log-report nil). Nil er nemlig også et objekt i Common Lisp – alt er objekter – og jeg har laget default implementasjoner av metodene som vil fungere for alle typer objekter! Alle linjene fra filen vil bli skrevet ut.
Det er på tide å se hvordan man definerer en ny klasse. Jeg vil nå opprette en klasse for å rapportere errors fra loggfiler, sånn som jeg gjorde i del 1. Til det bruker jeg DEFCLASS:
36 (defclass error-report () ())
Klassen arver ikke fra noe spesielt, og den har ingen properties, så den ble ganske minimal. Men som du vil se er den viktig likevel.
Jeg kan nå opprette nye metoder for de stegene i algoritmen/templaten som er interessante for error-rapporten. Disse metodene vil bli brukt i tilfeller hvor report-objektet er en instans av error-report.
42 (defmethod log-report-init :before ((report error-report)) 43 (format t "Errors:~%")) ; Printing a header.. 44 45 (defmethod log-report-process-line ((report error-report) line) 46 (let ((log-type (subseq line 18 23))) 47 (if (equal log-type "ERROR") 48 (format t "~a: ~a~%" 49 (subseq line 0 17) 50 (subseq line 24)))))
Metoden som prosesserer linjene vil erstatte default-implementasjonen, siden den ikke "kaller base/super" (i Common Lisp ville jeg gjort det ved å kalle en funksjon som heter CALL-NEXT-METHOD). Initialisering-metoden vil derimot bli lagt til i tillegg til eventuelt andre initialiseringsmetoder. I dette tilfellet skjer det fordi jeg har brukt :before-nøkkelordet. Before-metoder kaller i forkant av de virkelige metodene, og er bare en av mange måter man kan opprette metoder på.
Hvis jeg nå kjører koden (LOG-REPORT (MAKE-INSTANCE 'ERROR-REPORT)) så vil den skrive ut headeren og error-linjene fra filen jeg har mocket.
Nå oppretter jeg en ny klasse for FTP-stegene jeg trenger. Denne klassen arver heller ikke fra noen spesiell klasse, men inneholder én slot (property) for å holde på URLen til loggfilen.
58 (defclass ftp-report () 59 ((url :initarg :url))) 60 61 (defmethod log-report-init :before ((report ftp-report)) 62 (format t "Fetching ~a~%" (slot-value report 'url))) 63 64 (defmethod log-report-cleanup :after ((report ftp-report)) 65 (format t "Deleting ~a~%" (slot-value report 'url)) 66 (format t "Archiving local copy"))
Om jeg nå hadde evaluert (LOG-REPORT (MAKE-INSTANCE 'FTP-REPORT :URL "some url..")) ville metodene for å hente og slette FTP-loggen bli brukt, og default metoder for lesing og prosessering hadde også blitt brukt, slik at hele innholdet av filen hadde blitt vist. Men det er ikke det jeg er ute etter...
Jeg skal nemlig nå lage en ny klasse som arver fra både error-report og ftp-report:
68 (defclass ftp-error-report (ftp-report error-report) ())
Når jeg oppretter en instans av denne klassen, og så kjører log-report, vil metodene for klassene som arves bli kombinert:
71 (log-report (make-instance 'ftp-error-report 72 :url "ftp://foobar.com/logs/my.log"))
Dette gir altså følgende output:
Fetching ftp://foobar.com/logs/my.log Errors: 20120125180132112: Some error occurred 20120125180133056: Some other error... Deleting ftp://foobar.com/logs/my.log Deleting local copy as well
Et UML-diagram over denne modellen, om den hadde vært gjort i et mere klassisk OO-språk, ville sett ut som dette:
Jeg har altså brukt multippel arv til å gjøre Template Method mindre rigid enn løsningen jeg kom opp med i C# i del 1; nå kan jeg kombinere de ulike klassene på ulike måter i stedet for å ha en fastlåst arverekkefølge. Dette gjør denne løsningen mer utvidbar.
Jeg har ikke jobbet mye med objektorientering i Common Lisp, men synes systemet med de generiske funksjonene som ikke er knyttet direkte til klassene er ganske elegant. Det er kanskje ikke lett å se hvor fleksibelt dette er uten å forsøke litt selv, spesielt ikke om man er vandt til typisk klasse-basert objektoerientering fra språk som C#, Java eller C++, men det finnes nok av folk som skryter hemningsløst av Common Lisp's objektsystem. Dette er noe jeg må eksperimentere mer med.
Ønsker du en innføring i Common Lisp + objekter kan du ta en titt på Practical Common Lisp (online bok), kapittel 16 og 17.
I løpet av denne serien har du sett at et objektoerientert designpattern kan ha svært ulike implementasjoner. Et designpattern er ikke noe man kan pugge, og bare bruke igjen og igjen på samme måte. Man må tilpasse det omstendighetene, og hele tiden være klar over hvilke begrensninger det har. Jeg håper koden min har gitt deg noen ideer, og at du vil eksperimentere videre med hvordan du løser lignende problemer.