Laten we het eens over programmeren hebben. Da’s mijn vak, tenslotte. Ik leerde het in een andere eeuw op de HTS in Amsterdam, in de programmeertaal Algol 60. Niet een slechte taal om in te leren programmeren; beter dan Fortran of, nog erger, Basic (dat is geen taal, dat is een spraakgebrek). Een paar jaar later kreeg ik mijn eerste baan, bij het Bureau voor Statistiek van de gemeente Amsterdam. Mijn baas, Marten van Gelderen, vond dat ik me maar eens moest verdiepen in een nieuwe taal, Simula 67. Een taal die speciaal was ontwikkeld voor simulatiedoeleinden, met een nieuw concept: objecten. Een vooruitziende blik van Marten: 20 jaar later was het zgn. object-oriented programmeren helemaal hot. Toen waren we er namelijk achtergekomen dat ieder computerprogramma dat we maken eigenlijk een simulatie is: een simulatie van een systeem dat we eerst zonder computer gebruikten (denk aan een boekhouding of de post) of van een apparaat dat al bestond maar dat nu als programma op een computer draait (denk aan een typemachine of een rekenmachine, of een walkman, of een telefoon).

Objecten dus. Moderne software werkt (van binnen) met objecten. Maar wat zijn objecten? Het is eigenlijk heel simpel: objecten zijn de dingen die in werkelijkheid ook bestaan. De dingen die ons in het dagelijks leven omringen. De dingen waarmee we leven en werken en waarvan we een bepaalde verwachting hebben. We willen er iets mee doen, een object moet een bepaalde functie hebben. Denk aan een stoel: we willen erop kunnen zitten. Of aan een tv: we willen naar een bepaalde zender kunnen kijken. Of denk aan een fiets: we willen ons ermee kunnen verplaatsen. Maar een object kan ook een mens zijn: iemand aan wie we iets kunnen vragen. De bakker bij wie we een brood kopen, de leraar van wie we iets willen leren, een collega met wie we samenwerken. De hele wereld bestaat uit objecten, en die objecten maken op één of andere manier gebruik van elkaar. Van elkaars functies.

De objecten in software hebben ook allemaal een bepaalde functie (taak), en ze maken ook gebruik van elkaar. Ze komen niet per se overeen met objecten die in werkelijkheid ook bestaan (maar het zou wel kunnen). Ze komen soms overeen met de zichtbare elementen van de software: met een OK-knop op een web-pagina, met een vogel in de app Angry Birds, met een cel in een spreadsheet, of met een woord in een tekstverwerker. In andere gevallen zijn het minder tastbare, conceptuele dingen: een adres waarnaar we een e-mail sturen, of een betaling in een programma voor internetbankieren. De programmeur probeert het systeem dat hij of zij moet maken op te delen in kleinere deelsystemen. En die elk weer in nog kleinere deelsystemen, enzovoort. Tot er kleine behapbare stukjes overblijven die een duidelijk omschreven taak hebben. Inderdaad, de objecten.

Een programmeur moet leren denken in objecten. Ik merk tijdens alle trainingen die ik geef hoe moeilijk dat is. Terwijl het toch een natuurlijke manier van denken is, omdat de hele wereld bestaat uit objecten. Ik stimuleer mijn leerlingen om schema’s te maken van de objecten en van de relaties ertussen. Om in kaart te brengen wat de taken van de objecten zijn en welke andere objecten daarvan gebruikmaken. Een soort organisatieschema van een bedrijf, zou je kunnen zeggen. Waarin wordt weergegeven welke afdelingen of mensen er zijn, wat ze doen, en hoe ze samenwerken. Zo maakt de programmeur een organisatieschema van het programma dat moet worden gemaakt.

Als programmeur hebben we het overigens maar makkelijk: we kunnen zelf bedenken wat onze objecten voor taken hebben en ervoor zorgen dat ze die taken braaf uitvoeren. In een bedrijf, met “levende objecten”, is dat een stuk lastiger. Daar zijn de objecten niet zo braaf en doen ze niet altijd wat er van ze wordt verwacht. Arme managers. Ik blijf maar liever programmeur.

Advertenties