Sitat: “Den virkelige verden består bare av deltagere (roller). Algoritmer oppstår når de
kommuniserer.”

Veldig interessant kommentar, og observasjonen er nok korrekt. Likevel tror jeg at dersom mennesker tenker på algortimer som separate “ting” så kan det være verdifullt å bruke den ideen i koden. DCI-tanken om å få utviklerens (og brukerens) mentale modell inn i koden er årsaken til det. Dette er jo litt DDD tankegang. Allestedsnærverende språk, o.s.v.

Ett av argumentene jeg ser når Trygve og James (later som jeg kjenner de på fornavn) snakker om DCI er at i tidligere modeller var algortimen (“what the system does”) fragmentert på tvers av domene objektene (“what the system is”). For å løse dette lar de ulike objeter spille ulike roller i en gitt kontekst. Algoritmen er nå knyttet til rollen i den gitte kontekten, men er ikke algoritmen som tidligere var fragmentert på tvers av objektene, nå fragmentert på tvers av rollene? Jeg sier ikke at denne tankegangen er korrekt OOD, men det gir kanskje grunnlag til litt småfilosofering :) Å knytte algoritmene til rollene er uansett fremskritt.

Etter å ha undersøkt DCI nærmere ser jeg at det egentlig bare er en reformulering av Udi Dahans “Making roles explicit” presentasjon. Det er i alle fall en del av puslespillet. Hvem som kom først, skal jeg ikke uttale meg om.

Trygves ide om å lage vertøy som støtter DCI utvilkingsmodellen er spennende. Blir interessant å se hvilke verktøy som dukker opp i .NET verden i fremtiden.

Når det gjelder fri vilje, så tror jeg ikke at jeg skal gå inn på det. Det ville blitt for mye tekst for en kommentar. Jeg har ikke landet på “hard determinism”, men jeg er ikke langt unna.

Fra min anbefaling av Object Thinking: “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.”

Når vi designer algoritmer tenker vi at det finnes en sentral enhet som koordinerer ting. Jeg tror dette er en veldig menneskelig måte å se verden på. Vi tenker f.eks. at vi har en sentral, imperativ hjerne som styrer oss. Virkeligheten er anderledes – hjernen forstås bedre som en stor samling paralelle prosesser (med mye fuzzy logic) som kommuniserer og kommer opp med forslag og forståelse i felleskap.

Vi snakker også om at livet har mening, og at det er en mening bak ting. Vi ser på historien som en lineær hendelsesrekke som gir mening, selv om det ofte egentlig preges mer av kaos. Vi dikter opp overnaturlige krefter som står over oss og koordinerer – den ultimate algoritmen. Vi snakker om fri vilje, selv om begrepet ikke gir rasjonell mening.

(Mine innlegg om fri vilje: her, her og her.)

Mennesker setter ting i system for å forsøke å foutse hva som skjer siden. Vi gir systemene vi “ser” navn og tyngde, men systemene eksisterer egentlig ikke på den måten. De er samhandling mellom ulike entiteter. Helheten er større enn delene. På samme måte ønsker jeg å designe software som er større enn objektene det består av. Algoritmen er måten objektene kommuniserer på!

Jeg tenker at spørsmålet ditt egentlig dreier seg mer om DDD. Hvordan ser forretningsfolkene i dette domenet på verden? Når de snakker om en transaksjon, fokuserer de da på de to kontoene, eller ser de på selve transaksjonen som en entitet i seg selv? Er det siste mest riktig kan det være naturlig å si at transaksjonen er en egen rolle. Etter at vi har avgjort det kan vi bruke DCI for å implementere, og har da tre roller: MoneySource, MoneyDestination og MoneyTransaction. MoneyTransaction er nå ikke konteksten, men en fullverdig rolle – konteksten kommer i tillegg.

Jeg har aldri jobbet i bank, og vet ikke hva som vil være mest forståelig for en i det domenet, men for meg virker det mest naturlig å ikke modellere MoneyTransaction som en egen rolle. Den “orginale” OO-ideen var at objekter snakker sammen for å oppnå adferd, mens å lage et transaksjons-objekt for å inneholde transaksjonslogikken egentlig er prosedyre-tankegang i forkledning. Men det finnes mange måter å designe software på, og få fasiter.

Men for å svare helt klart på spørsmålet ditt (i forhold til min forståelse av DCI): Poenget med rollene DCI er å samhandle. Samhandlingen skal ikke implementeres “på utsiden” (i konteksten).

Den virkelige verden består bare av deltagere (roller). Algoritmer oppstår når de kommuniserer. Dette er det Dr. David West kaller Object Thinking (anbefaler boken). I imperativ programmering fokuserer vi ofte på å implementere algoritmer steg for steg, og dette er altså ikke, i følge en del kloke hoder, god bruk av objektorientering. Fantastisk software oppstår når objekter “snakker sammen” som i den virkelige verden.

@Torbjørn: Spennende artikkel som satt igang mye lesing her i gården :) Et spørsmål: Er det mening at all logikken skal være knyttet til rollene (MoneySource,MoneyDestination), eller kan man tenke seg at logikken ligger i konteksten (MoneyTransfer) ?

I ditt eksempel kunne man tenkt seg at “transfer” logikken kunne vært plassert i MoneySource (slik som du gjorde), eller MoneyDestination. Den kunne også vært plassert i MoneyTransfer som da ville hatt transaksjonslogikken o.s.v.

Hva om man hadde tre, fire eller fem roller som skulle spille sammen ? Ville det ikke da vært natulig å ha transaksjonslogikken i konteksten og ikke nøvendigvis i rollene. Rollene er bare deltagere i det store spillet (e.g. algoritmetn) i konteksten.

Hva sier DCI om dette ? Noen tanker ?

Så med litt AOP så får man til DCI i Java, og sikkert i C# også :)

Når det gjelder MANGE klasser.., i utgangspunktet ikke noe problem. Mange klasser er langt å foretrekke fremfor få og store klasser – det hjelper på å holde koblingen mellom ting til et minimum. Forestill deg et system som 10 utviklere har jobbet på i et års tid: Du åpner en vilkårlig fil og finner en klasse på kanskje 10-15 linjer, og på få sekunder skjønner du akkurat hvorfor klassen eksisterer og hvordan den fungerer, uten å måtte se i noen andre filer. Det er målet med god objektorientering!

Det finnes desverre ikke mange slike, men idealer er bra :)

Jeg skjønner hvordan objekt-orientering gjør kodebaser mer skalerbare og slikt, ja, og hvis det må bli et par tusen linjer før du kan vise til redusert arbeid skal du få slippe. Jeg bare forestiller meg at hvis du skal ha en klasse til hver rolle blir det en del slike etterhvert.

Her er et nytt eksempel i Haskell som kanskje er litt mer DCI-ete: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24161#a24161
Forskjellene er at jeg delte opp Balanceable i MoneySource og MoneyDestination og flyttet det over i STM-monaden (Software Transactional Memory) for atomisk oppdatering, beskyttet fra andre tråder og whatnot. STM lar seg dog ikke blande med databasetransaksjoner da disse krever IO, men det er relativt enkelt å legge til “Database.HDBC.withTransaction” på det forrige eksempelet.

Det enkleste Haskell-eksempelet jeg kom på var http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24162#a24162

http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24155#a24155

Virker det enklere nå?

Her er den enkleste Ruby-løsningen jeg kommer opp med om jeg ikke bruker DCI (eller objektorientering i det hele tatt): http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24158#a24158 Dette er ikke noe jeg vil brukes i en real-life løsning.., men det er i alle fall en del enklere enn Haskell-implementasjonen.