Diverse programmeertalen, zoals Java, C++, C# en Smalltalk, ondersteunen concepten die voortkomen uit de wereld van object-oriëntatie (oo). Ook ontwikkelmethoden en technieken, zoals UML, hebben al jaren geleden dezelfde concepten geadopteerd, en ze zijn zelfs binnen relationele databaseservers opgenomen.
Laten we ons richten op de combinatie van object-oriëntatie en programmeertalen. De vraag rijst of het ontwikkelen van oo-programma’s niet te complex is voor vele programmeurs en … leidt het niet tot zeer lastig te onderhouden programmastructuren? Is object-oriëntatie voor de programmeur niet een doodlopende straat, zijn we niet in een Echnatonse periode beland?
Wat zegt u? Een korte toelichting is waarschijnlijk noodzakelijk. Farao Echnaton is nooit zo populair geweest als zijn zoon Toetanchamon, die door de spectaculaire opgravingen veel meer publiciteit gekregen heeft. Voordat Echnaton regeerde, geloofden de Egyptenaren in vele goden. Toen hij aan de macht kwam, verbood hij het vereren van al die goden, iedereen mocht er slechts één aanbidden: de zonnegod. Al die jaren dat deze monotheïst aan de macht was, waren zijn onderdanen doodsbang dat de andere goden verbolgen zouden omdat ze niet vereerd werden. Echnaton was nog niet weg, of alle goden werden weer snel uit de kast gehaald. De gehele periode werd vergeten en de klok werd weer zeventien jaar teruggedraaid.
De vraag is nu, bevinden we ons met het toepassen van oo-concepten binnen programmeertalen ook niet in zo’n Echnatonse fase? Bevinden we ons in een fase waar we door de komst van bepaalde programmeertalen tegen onze wil in terechtgekomen zijn?
Als je kortgeleden informatica hebt gestudeerd, zal iedereen het normaal vinden dat je veel ervaring hebt met oo-programmeertalen. Maar voor een doorsnee programmeur, opgegroeid met klassieke talen als Cobol, RPG en Fortran, is het een grote stap. Er gaat een lange tijd overheen voordat men zich thuis voelt met dit soort talen. We onderschatten dat vaak. Het verklaart deels waarom het nog steeds lastig is goed geschoolde Java-programmeurs te vinden.
Trouwens, Microsoft heeft besloten om zijn paradepaard Visual Basic om te toveren tot een volwaardige oo-taal, genaamd Visual Basic.Net.
De volledige Visual Basic-wereld is in rep en roer, want die ziet haar simpele programmeertaal ineens veranderden in iets waar zij geheel niet op zat te wachten.
Natuurlijk is de herbruikbaarheid van code door middel van overerving een prachtig concept, maar hierdoor ontstaan er tevens vele impliciete relaties in onze code. Het is moeilijk te overzien welke invloed een verandering van code heeft op andere delen van de applicatie. Door de impliciete code ontstaan er teveel afhankelijkheden tussen verschillende delen van programma’s. Veronderstel dat een stuk code gewijzigd moet worden, terwijl andere stukken code hiervan eigenschappen erven. Onderhoud gaat dan lijken op het spelen met mikado-stokjes. Je pakt er een beet, en op de vreemdste plekken beweegt er wat in de berg met stokjes. Ooit is mij geleerd dat het aantal afhankelijkheden tussen stukken code beperkt dient te worden.
Impliciet programmeren kan voordelen hebben als de programmeurs een lange periode aan een applicatie mogen werken. Zij ontwikkelen de applicaties en voeren er jarenlang onderhoud op uit. In dat geval kan door gebruik te maken van overerving en ‘overloading’ zeer compacte code geschreven worden. Echter, in de meeste bedrijven blijven mensen niet lang bij een applicatie, ze promoveren of worden overgeplaatst naar een ander project.
Bij softwarefabrikanten zien we juist wel dat personen lang betrokken zijn bij dezelfde applicatie. Misschien wordt het ook eens tijd dat we onderscheid maken tussen applicatiebouw door softwarefabrikanten en door softwaregebruikers. Bij deze partijen spelen verschillende belangen en is het begrijpelijk dat er andere gereedschappen ingezet worden.
Voor een applicatie, gebouwd door een softwaregebruiker, zouden we programmeertalen moeten gebruiken die zo expliciet mogelijk zijn. Veranderen we een stukje code, dan weten we dat we ook alleen maar dat stukje veranderen en niet ongewenst andere delen. Natuurlijk zal dit er toe leiden dat er minder code opnieuw gebruikt wordt, maar de code wordt wel beter onderhoudbaar.
Let wel, het is niet zo dat ik geheel geen toepassing zie voor oo-programmeertalen bij softwaregebruikers. Sommige stukken code kunnen zo complex zijn, dat ze alleen met oo-programmeertalen elegant op te lossen zijn. Maar veel van de code die geschreven wordt bij softwaregebruikers is helemaal niet zo complex, maar zijn klassieke administratieve systemen.
Ik heb niet de illusie dat ik mijn eentje deze oo-beweging kan terugdraaien. Maar ik hoop wel dat het deze discussie, die eigenlijk nooit goed gevoerd is, op doet laaien. Is het gebruik van oo-concepten niet te complex voor een gemiddelde programmeur en leidt het gebruik van oo-concepten in programmeertalen bij softwaregebruikers niet tot zeer lastig te onderhouden software? Of met andere woorden, bevinden we ons nu wel of niet in een Echnatonse fase? Ik ben benieuwd of mensen hier over gaan nadenken.
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
