When Rome is lost in her ways

 
25 juli 2011

“Er zijn meer wegen die naar Rome leiden”
VIARome
zegt het bekende spreekwoord, met de implicatie: “Verschillende paden kunnen worden bewandeld om bij hetzelfde doel uit te komen.”

Vertaalt naar softwareontwikkeling zou dit kunnen inhouden dat er verschillende manieren mogelijk zijn om een bepaalde oplossing te implementeren. Of, een probleem die op verschillende manieren op te lossen is. Maar, laten we eens op een andere manier naar dit gezegde kijken en het ‘Rome’ uit dit spreekwoord eens als metafoor van de idee zien. Vanuit dit licht bezien zou dat inhouden dat het ‘Rome’ uit dit spreekwoord, de vertaling is van onze idee naar code. De ‘[toegangs]wegen’ zijn dan dat deel van de code die onze core toegankelijk maakt. We kunnen ‘Rome’ via verschillende wegen laten benaderen. Deze wegen zijn echter enkel faciliterend en hebben ook als enige doel om Rome te ontsluiten. [1] Wegen kunnen worden verwijderd, nieuwe kunnen worden aangelegd, echter Rome zal moeten blijven bestaan.

Gevaren
Wanneer we de applicatie, of een deel ervan, bezien vanuit deze indeling: Rome en zijn toegangswegen, zijn er twee uitersten denkbaar die als gevaar aangemerkt kunnen worden:
1) Rome wordt uit elkaar gescheurd door de infrastructuur. We zien het al voor ons. Een vierbaans snelweg vlak langs het Colosseum en een groot heliplatform in het midden omdat deze goed bereikbaar moet zijn voor toeristen. Gevaar: Rome wordt flink toegetakeld door de infrastructuur.
2) De wegen worden zo vaak gebruikt dat men Rome ongemerkt daarop gaat uitbreiden. Zodoende wordt Rome steeds groter en steeds minder compact. Als een inktvlek verspreidt het zich over de toegangswegen. De wegen worden vervolgens belangrijker dan Rome zelf, sterker nog, in plaats van ‘Er zijn meer wegen die naar Rome leiden’ wordt het eerder ‘Er zijn meerdere delen van Rome op verschillende toegangswegen’. In het ergste geval is Rome niet meer te onderscheiden van de toegangswegen. Gevaar: We kunnen geen wegen meer muteren zonder Rome zelf daarin mee te nemen. Tevens wordt Rome lastig onderhoudbaar omdat de spreiding zo groot is.

Toepassing
Op macroniveau zouden we het domein van de applicatie ten opzichte van het gebruikte framework kunnen vergelijken. Rome is hier het domein, het framework faciliteert en vertegenwoordigt dus de toeganswegen. Het framework leent zijn bestaansrecht puur bij de gratie des domeins. Hier treedt mijns inziens snel het gevaar op dat het framework een dusdanige stempel drukt op het domein dat het eerste gevaar, Rome wordt verscheurd door de infra, daarop van toepassing is. Het framework kan bijvoorbeeld eisen dat iedere klasse erft van een framework-baseclass, wat implicaties heeft voor het objectmodel. De vraag die hier gesteld moet worden is: ‘In hoeverre worden de keuzes die ik maak, bepaald door het gebruikte framework?’. En, misschien wel de hamvraag: ‘Kan ik mijn core-applicatie nog verhuizen naar een [totaal afwijkend] framework?’

Op microniveau is het voorbeeld van een RAD-applicatie van toepassing. Hiermee wordt bepaalde logica min of meer opgebouwd vanuit GUI-bouwstenen. We slepen wat GUI-elementen naar het scherm en bouwen vervolgens onze applicatie op / werken ons idee uit. Doordat de GUI-elementen leidend zijn voor de chronologische totstandkoming van onze applicatie-logica kan het gebeuren dat de onderlinge samenhang tussen de verschillende methoden niet goed wordt bewaard. Zo kunnen er verschillende methoden ontstaan die eigenlijk in één enkele methode thuishoren. De logica is dus meer gestructureerd volgens de GUI-componenten dan hun onderlinge samenhang. Hiermee hebben we dus het tweede gevaar te pakken: Rome is verspreid over de toegangswegen (de GUI met diverse event-handlers). De vraag die op dit niveau gesteld moet worden is: ‘Wat drijft de indeling van mijn klassediagram?’

Conclusie
“Er zijn meer wegen die naar Rome leiden”, jawel, maar laten we erop letten dat het ‘Rome’ behouden blijft in onze applicatie. Toegangswegen zijn nodig om al het moois te ontsluiten maar kunnen uw idee flink toetakelen. Mijns inziens moet het verschil, tussen Rome en wegen, in iedere applicatie duidelijk zichtbaar zijn. Welke code is ondersteunend, zoals boilerplate-code, en welke coderegels omvatten de echte core – de idee zelf? [2] Uiteraard is dit niet zwart-wit. Er is geen goed of fout. Men zal in iedere situatie de juiste afweging moeten maken.

Tenslotte
There was once a dream that was Rome.

You could only whisper it.

Anything more than a whisper and it would vanish…

it was so fragile.

And I fear that it will not survive the winter. [3]

Ergo, laat uw idee niet ten ondergaan in een implementatie. Want de winter is in aantocht en de donkere [?] wolken van the cloud pakken zich al samen.


1. Een zelfde visie op DDD als het zonnebloemmodel met betrekking tot de impact die de ‘blaadjes mogen hebben op de zaadjes (zonnebloempitjes)’, maar dan inverse.
2. Druk deze regels, die uw idee implementeren, af op een mooi delfsblauw tegeltje en geef het een mooi plekje.
3. Uit de film: Gladiator.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development


Reactie

  • Bla schreef:

    Volgens mij is het spreekwoord wel ‘alle wegen leiden naar Rome’, met dezelfde betekenis.

    Geplaatst op 23 augustus 2011 om 9:38 Permalink