Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Geloofsstrijd rond de farao en object-oriëntatie

Dit artikel delen:

Soms heeft de discussie over programmeertalen het karakter van een geloofsstrijd, waarin niet argumenten maar veeleer openbaringen van zelfverklaarde profeten de boventoon voeren. Ik heb mij, schrijft Frank Koldijk, in dergelijke discussies niet onbetuigd gelaten en ook aan deze discussie over object-oriëntatie kan ik mij niet onttrekken.

Veelzeggend vind ik het dat columnist Rick van der Lans onze huidige tijd een Echnatonse periode noemt. Niet dat ik het ermee eens ben; van een al dan niet gedwongen aanbidding van een enkele programmeertaal lijkt mij momenteel toch nauwelijks sprake. Wel heeft de discussie over programmeertalen soms het karakter van een geloofsstrijd, waarin niet argumenten maar veeleer openbaringen van zelfverklaarde profeten de boventoon voeren. Ik heb mij in dergelijke discussies niet onbetuigd gelaten (zie mijn polemiek met René Veldhuis over het relationeel paradigma in DB/M), maar ik hoop toch dat men mij niet als een zeloot ziet. Ik maak mijzelf wijs dat ik de discussie altijd met rationele argumenten voer, al besef ik ook dat niemand zich helemaal kan onttrekken aan zijn bewuste of onbewuste persoonlijke of ideologische voorkeuren.
Als ik de column 'Object-oriëntatie en farao Echnaton' (Computable, 11 mei) goed begrijp, dan heeft Van der Lans een persoonlijke voorkeur met mij gemeen: eenvoud en overzichtelijkheid in programmeren. Die voorkeur brengt hem tot een afwijzing van object-oriëntatie (oo), althans voor toepassing door de hoofdmoot van softwaregebruikers. Het is diezelfde behoefte aan helderheid en begrijpelijkheid die mij juist in de armen van oo heeft gedreven. Hoe is het mogelijk dat eenzelfde streven tot twee zulke (schijnbaar) tegengestelde conclusies kan leiden?

Schijnbare tegenstelling

Ik plaats hier bewust het woordje 'schijnbaar', want misschien is onze tegenstelling minder groot dan hij lijkt. In elk geval kan ik met hem meegaan als hij zegt dat we eindgebruikers en applicatiebeheerders niet moeten opzadelen met de noodzaak tot programmeren in lagere talen (maar dat geldt wat mij betreft ook voor talen als Cobol, RPG of Pascal en niet alleen voor C++ of Java). In plaats daarvan zouden we deze gebruikers moeten uitrusten met een set handige tools voor manipulatie en presentatie van data. SQL is wel ongeveer het uiterste dat je zo'n gebruiker kunt aandoen. We zijn het er ook over eens dat heel complexe softwareproblemen alleen met object-oriëntatie nog 'elegant' op te lossen zijn. De discussie gaat over de vraag of we oo moeten inzetten voor klassieke administratieve systemen. Ik denk dus van wel, maar ook dat weer met de nodige nuance.
Ten eerste meen ik dat oo als concept juist bij uitstek geschikt is om complexiteit te beheersen en herbruikbaarheid te bevorderen. Een sterk concept alleen is echter niet genoeg. Daarom denk ik, ten tweede, dat wie object-oriëntatie omarmt er ook goed in opgeleid moet zijn, niet in de syntax van een eventuele taal, maar juist in de achterliggende theoretische grondslagen. Ten derde is een goede ontwikkelomgeving elementair en ik beschouw C++ of Java nadrukkelijk niet als goede talen of tools. Misschien is dat wel de belangrijkste reden voor zijn afkeer van object-oriëntatie: een stukje code in die talen is inderdaad nodeloos cryptisch (zeg maar gerust onverteerbaar voor niet-ingewijden). Wat we nodig hebben is een soort objectgeoriënteerd Cobol.

Stellingen

Mijn eerste stelling is gebaseerd op het modulaire karakter van object-oriëntatie. Alle eigenschappen die relevant zijn voor een bepaald type objecten zijn vervat in het concept van de klasse. Het werken met klassen als architectonische basiseenheid biedt tal van voordelen (directe 'mapping' van probleemdomein naar software; minimaal aantal interfaces; expliciete interfaces, inkapseling van implementatiedetails). Klassen lenen zich voor toepassing van concepten als (meervoudige) overerving en 'genericiteit' waardoor bestaande software opnieuw is te gebruiken met een minimum aan inspanning.
Mijn tweede stelling, dat goede scholing elementair is voor een professionele toepassing van object-oriëntatie, is minder triviaal dan hij lijkt; oo gaat veel verder dan het in elkaar flansen van een stukje Javacode. Inzicht in de achterliggende theorie van de Abstracte Datatypen (ADT) is mijns inziens van wezenlijk belang, maar ik heb niet de indruk dat veel programmeurs of ontwerpers daar enige kaas van hebben gegeten (met uitzondering wellicht van degenen met een universitaire informatica-achtergrond). In feite zou iedereen die in een oo-taal programmeert, ontwerpt of er zich een mening over aanmatigt, 'Object Oriented Software Constructie' van Bertrand Meyer gelezen moeten hebben.
Ten slotte, de noodzaak van een goede taal- of ontwikkelomgeving.
Het probleem bij hergebruik van software is niet de aanwezigheid van wat Van der Lans 'de vele impliciete relaties in onze code' noemt. In object-oriëntatie zijn relaties namelijk altijd expliciet gedeclareerd: ofwel als een 'inheritance'-relatie ofwel als een 'client'-relatie. Het probleem is dat die relaties in code van de meeste talen niet volstrekt transparant zijn. Een goede programmeur kan en zal deze relaties 'uitcommentariëren', maar wat je in de meeste talen mist is dat die transparantie, net als in Cobol, door de syntax wordt afgedwongen.

De taal Eiffel

Ik ken eigenlijk maar één volwassen objectgeoriënteerde taal waarin dat consequent gebeurt en dat is Eiffel (niet te verwarren met het gelijknamige Nederlandse softwarehuis). Vooral de mogelijkheid in Eiffel om de eigenschappen van een klasse en haar features formeel te beschrijven met behulp van post- en precondities en in varianten, is uitermate nuttig bij het hergebruik. Maar ook een goede ontwikkelomgeving met een slimme klassen-browser kan veel bijdragen aan het inzichtelijk maken van relaties, die in werkelijkheid nu eenmaal ook vaak sterk vertakt zijn en die in klassieke talen de beruchte spaghetticode veroorzaken.
Het is mij overigens een raadsel waarom de taal Eiffel in Nederland vrijwel volledig genegeerd wordt. In een van de laatste nummers van de Automatiseringgids werd geschreven over een nieuw patiënten-registratiesysteem voor een groot ziekenhuis. De leverancier ervan liet de journalist van AG trots weten dat het geschreven was is Java en C++. Een leugentje, want het betrof Eiffel. Kennelijk is men bang niet helemaal voor vol te worden aangezien als men een 'eenvoudige' taal gebruikt, ook al is die minstens even krachtig als de taal die in de mode is.
Ik moet nu oppassen: met het ophemelen van Eiffel dreig ik mijzelf, mijns ondanks, het predikaat van predikant op de hals te halen. Daarom laat ik het hier bij de suggestie om eens wat te bladeren in bovengenoemd boek.
 

Frank Koldijk Hillegom

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2001-06-01T00:00:00.000Z Frank Koldijk
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.