Liever lui dan moe

Door Arjen Uittenbogaard

In deze stukjes leg ik uit hoe object-oriëntatie naar de wereld kijkt en wat dat oplevert. Een OO-model van een systeem, of het nu een IT-systeem is of een organisatie, gaat uit van verantwoordelijkheden die door samenwerkende objecten worden waargemaakt. Een goed OO-model is flexibel genoeg om complexe en veranderende situaties aan te kunnen. In het vorige stukje beschreef ik de essentie van OO: het beschrijven van de wereld in termen van actieve objecten die gedrag vertonen en kennis hebben. Objecten met duidelijk omschreven verantwoordelijkheden. Hier wil ik die verantwoordelijkheden verder bekijken, vanuit het motto: liever lui dan moe.

Ik vind dit een mooi motto: voordat ik ga rennen en vliegen om iemand een dienst te verlenen, is het goed om even na te denken waarom ik dat zou doen. Moet ik het wel doen? Misschien kan iemand anders het veel beter dan ik. In een OO-model streven we ernaar om objecten een duidelijk afgebakende verantwoordelijkheid te geven en ook niet meer dan dat. Een deur gaat over toegang verlenen, een lift over verticaal transport, een vakantie over ontspanning. Als we een deur ook nog, zeg, post willen laten ontvangen (omdat er nou eenmaal in sommige deuren een brievenbus zit), moeten we ons even achter de oren krabben. Hoort post ontvangen bij de essentie van een deur? Hoe meer verantwoordelijkheden we een object geven, hoe vaker dat object aangepast moet worden als we ook maar iets in het systeem willen veranderen. De juiste denkwijze in zo’n geval is om de gewenste nieuwe verantwoordelijkheid goed te benoemen en dan het object te vinden dat deze verantwoordelijkheid logischerwijs draagt. Als we de ontvangst van post in het model mee willen nemen, laten we daar dan een specifiek nieuw object voor definiëren, ik noemde het al: de brievenbus.
Een houding van liever lui dan moe leidt zo tot het definiëren van nieuwe objecten. We hebben een nieuw te realiseren verantwoordelijkheid onderkend, dus is een nieuw object nodig. Tot nu toe sprak ik over objecten die moeten doen waar ze voor zijn, maar dat kan alleen maar als ze samenwerken met andere objecten. Als post door de deur binnenkomt, maar de brievenbus heeft de verantwoordelijkheid post te ontvangen, moet de brievenbus de post wel doorgeven aan de deur. Als een lift verticaal moet transporteren, maar de kabels leveren trekkracht, dan moet die trekkracht wel doorgegeven worden aan de lift. Als een vakantie ontspanning moet geven, maar daarvoor is een strand met wuivende palmbomen nodig, dan moet ook hier worden samengewerkt. Liever lui dan moe werkt alleen als iedereen doet wat hij moet doen en er met elkaar wordt samengewerkt. Ik stel me wel eens voor hoe het eruit zou zien als ik mijn computer kon openmaken en met een speciale bril kunnen kijken wat er zich daarbinnen afspeelt. Wat ik dan in gedachten voor me zie is een marktplein waar het krioelt van samenwerkende objectjes.

Het belang: aanpasbaarheid door samenwerking
Langzaamaan ontstaat zo een model met samenwerkende objecten. Laten we eens kijken wat dat oplevert, zowel in IT-systemen, maar ook in organisaties die we zo modelleren.
Tot nu toe werkte de lift samen met kabels die trekkracht leveren. Maar wellicht zijn er ook stuwraketten. Daar kan de lift ook mee samenwerken om omhoog of omlaag te gaan. Door het leveren van vermogen buiten de lift te houden, hebben we de mogelijkheid gecreëerd om flexibeler te zijn in de mogelijkheden van het resulterende systeem. Als we later nieuwe manieren van trekkracht bedenken, kunnen we die toevoegen zonder dat we het huidige systeem hoeven aan te passen. Het enige dat nodig is, is ervoor zorgen dat de lift die nieuwe mogelijkheden ook kan ontdekken. (Misschien leidt dat wel weer tot nog een nieuw object. Een dat objecten vindbaar maakt voor elkaar. Ziehier de gouden gids.) De luiheid van de objecten, dat wil zeggen hun heel gefocuste verantwoordelijkheid, levert flexibiliteit.

Een ander voorbeeld waar deze flexibiliteit waardevol is, is bij het beschermen van het systeem. De aanname die ik tot nu toe alsmaar maak is dat elk object doet wat het moet doen. Maar wat nou als dat niet zo is? Een IT-systeem kan gehackt worden en ook in een organisatie gaat wel eens iets mis. De goede OO aanpak in dat geval is te bedenken dat we dus blijkbaar nieuwe verantwoordelijkheden nodig hebben, lees: nieuwe objecten. Kwaadwillenden moeten buiten de deur gehouden worden? Dat vraagt om een poortwachter. Gegevens moeten onleesbaar gemaakt worden? Dat vraagt om een codeerder. Wat we dus niet doen, is de bestaande objecten uitbreiden met deze extra taken. Als je daaraan begint is het hek van de dam. Dan moeten binnen de kortste keren allerlei objecten zich naast hun eigen verantwoordelijkhied, zich ook als poortwachter gaan gedragen. En als de manier van bewaken later moet veranderen, dan moeten ál die objecten aangepast worden. Nee, geef elk object dat beschermd moet worden een poortwachter en weet dat je alleen dát object hoeft aan te passen bij nieuwe beveiligingsmaatregelen.

(Hardcore IT-ers wijs ik erop dat elk design pattern óók een toepassing van ‘liever lui dan moe’ is. Elk pattern gaat namelijk over het flexibel maken van een heel goed te definiëren verantwoordelijkheid door er een nieuw object voor verantwoordelijk te maken. Creëren van objecten? Dat vraagt om factories. Toestandsafhankelijk gedrag? Dat vraagt om state objecten. Boomstructuren? Dat vraagt om composites. Stuk voor stuk objecten die voor dat ene specifieke doel zijn geïntroduceerd.)
(En nu ik die hardcore IT-ers toch aan het aanspreken ben, vergeef me dat ik objecten en klassen zo door elkaar haal in deze stukjes.)

Wat hebben we aan ‘liever lui dan moe’ als het systeem onder beschouwing een organisatie is? Een voorbeeld uit de praktijk. In een softwareproject wilden we uitzoeken hoe we volgens een nieuwe methode konden werken. We spraken af dat we binnen het project alles op de nieuwe manier zouden doen. We gebruikten een modelleeromgeving waarin al onze modellen konden worden opgeslagen en werkten met de rollen en processen die door de methode werden beschreven. Maar natuurlijk zaten we niet op een eiland waar we vrij onze gang konden gaan. Aan de randen van het project grensde de staande organisatie die van alles van het project verlangde. Een stuurgroep die rapportages wilde en een kwaliteitsorganisatie die erop stond dat bepaalde documenten werden opgeleverd. Wij vonden die rapportages en documenten overbodig, want dergelijke informatie zat al in onze ontwikkelomgeving of hing aan de muren van de teamruimte. Maar we konden hoog of laag springen, deze vragen uit ‘de oude wereld’ konden we niet negeren. Toen bedachten we dat dit een bekend vraagstuk was. Namelijk als je een nieuw systeem maakt dat gekoppeld moet worden aan een oud systeem, wil je dat nieuwe systeem niet corrumperen met oude systeeminterfaces –voor je het weet introduceer je allerlei oude problematiek in het nieuwe systeem. Het oude systeem, aan de andere kant, kún je vaak niet eens aanpassen. De oplossing? Het toevoegen van een adapter. Een nieuw object met de specifieke verantwoordelijkheid om twee systemen te koppelen. Liever lui dan moe. Dat werd ook in ons project de oplossing. We introduceerden een nieuwe rol in het team: de ‘Oude-wereld-adapter’. Degene die deze rol vervulde moest op vrijdagmiddag alle informatie uit onze systemen halen en overzetten in de formaten die door stuurgroep en kwaliteitssysteem verlangd werden. Het was geen leuke rol, dus we rouleerden hem. Maar dankzij deze rol kon het team gewoon doorwerken alsof die vervelende oude wereld er niet was.

Tot slot nog een opmerking naar aanleiding van wat ik in het begin van dit stukje schreef: “… voordat ik ga rennen en vliegen om iemand een dienst te verlenen, is het goed om even na te denken waarom ik dat zou doen. Moet ik het wel doen? Misschien kan iemand anders het veel beter dan ik.” Begrijp me goed. Ik heb het niet over wat we in een project ooit ‘SNIF-gedrag’ noemden: “Staat Niet In mijn Functieprofiel…” als reden gebruiken om niet mee te werken. Dit is kwalijk gedrag vanuit het oogpunt van een gezamenlijke verantwoordelijkheid die het team, de unit, de organisatie heeft jegens bijvoorbeeld de klant. In een OO-model zou dat team, die unit of organisatie zelf óók weer een object zijn. Een object dat iedereen kent met de benodigde vaardigheden en met hen samenwerkt zodat gedaan wordt wat gedaan moet worden. Het is een leuke exercitie om te bedenken hoe dit model eruit zou zien.

Arjen Uittenbogaard

Arjen is verhalenverteller. Een training van hem is een ervaring die je niet licht vergeet. Hij is ook regisseur van improvisatietoneel. Dat vindt hij een mooie metafoor voor zijn werk in het coachen van teams en individuen in organisaties die meer agile willen worden. Want dat is zijn expertise: agile werken. Daar heeft hij al twintig jaar ervaring mee en daar is hij goed in. Zijn hart gaat uit naar de menselijke kant van het werk, naar de communicatie en de samenwerking. Daarbij weet hij alles van complexe adaptieve systemen: omgevingen waarin niets is wat het lijkt, waar best practices je op het verkeerde been kunnen zetten en waar je steeds zult moeten experimenteren en leren. Ook heeft hij nog steeds lol van zijn achtergrond in object georiënteerde softwareontwikkeling: hij mag ontwikkelaars graag uitdagen op hun ontwerpen en de toepassing van design patterns daarin.

06 - 59 443 440

Andere posts

Klik hier