Data-Context-Interaction med fadern av MVC

Jag valde att viga sista dagen på Öredev åt DCI, ett nytt paradigm för hur vi ska strukturera objekt-orienterade system för att bättre kunna begripa koden. Varför då kan man fråga sig? Helt enkelt därför att det väckte mitt intresse att man lagt in hela tre pass, totalt 5h föreläsningar, med detta ämne. Dessutom var föreläsarna riktiga tungviktare. Trygve Reenskaug är känd som uppfinnaren av MVC-mönstret och har arbetat med programmering sedan 1950-talet. När en sådan veteran väljer att uttala sig och dessutom får med sig en hel drös av yngre förmågor, som Rickard Öberg och den relativt unga James Coplien (alias Cope), så kan det vara värt att lyssna. Jag tillhör nämligen den skara som tror att vi har något att lära oss av de äldre.

Uppfinnaren av MVC Trygve Reenskaug, En  sådan progammerarstjärna vill man ju ha en bild med.

DCI står för Data-Context-Interaction. Trygve förklarade historien bakom hur han kom fram till behovet av ett nytt mönster. Enligt honom så var procedural programmering ett mycket lyckat koncept. Objekt-orientering var tänkt att bygga vidare på detta koncept, men de ursprungliga idéerna som fokuserade på Objekt och inte klasser, glömdes bort och vi fick klassbaserad OO som har lett till program som är svåra att förstå på grund av att koden för ett specifikt Use-Case har smetats ut över ett antal klasser. Vi har alltså inte uppnått god "Separation of Concern". Lösningen enligt Trygve är att gå ifrån klass-baserad OO och istället fokusera på objekten och dess roller. Hans tidigare arbeten har också handlat om rollmodellering. Tanken med DCI är att programmet skall struktureras enligt följande:
1. Data - Dumma domänobjekt med relationer och andra saker tillhörande domänen som inte ändras allt för mycket, t ex deriverade attribut och relationer.
2. Context och Interaction- Ett kontext mappar i princip till ett Use-Case, till detta binder man sedan upp objekt som ska fylla de roller som behövs för Use-Caset. Rollerna innehåller objektens beteenden. Varje objekt har oftast flera roller. Rickard Öberg berättade i sin presentation att ett typiskt objekt i deras nya workflow-system (byggt på qi4j såklart.), implementerar ca 20 roller.

Vad ger oss då DCI? Jo, genom lite gott verktygsstöd så kan vi enklare se var i koden ett Use-case är implementerat. Use-casest blir till sin natur mer proceduralt. Med tillägget att undvika polymorfism i rollerna får man också ett tydligare programflöde som kan läsas lättare. Man undviker på detta sätt också att skapa monster-objekt som ska klara av allt. Det finns redan idag ett antal implementationer av konceptet i olika språk t ex C++, Ruby och Python. I Java finns qi4j (Kommer snart i version 1.0). Trygve, sin vana trogen från Xerox PARC, använde förstås Smalltalk och en tweakad Squeek-miljö.

Vad skall man då säga om allt detta? Sådan saker som inmixade roller tycker jag tveklöst är av godo. Javas bristande stöd för komposition är en katastrof. Som forskare inom AOP-området har jag också en förkärlek för Separation of Concern-tekniker och detta är definitivt en av de mer intressanta. Framförallt eftersom den går rakt på affärslogiken och inte bara, som mest var fallet tidigare, rörmokeriet. Det som eventuellt gör mig lite fundersam är de dumma domänobjekten.