Echnaton zal wel gedacht hebben ‘OOPs!’ toen alles na zijn dood werd teruggedraaid. Men probeerde zelfs die hele periode ongedaan te maken door onder andere zijn naam overal uit weg te bikken! (Ben ik de enige die hier een parallel ziet met Java, Microsoft en C#?) OOP staat normaliter voor Object-Oriented Programming, maar in dit geval, vindt Wen Hu, zou je misschien ook kunnen spreken van een (ogenschijnlijke?) Object-Oriëntatie-Paradox.
Om te beginnen ben ik het bijvoorbeeld niet eens met de stellingen van Rick van de Lans in zijn column ‘Object-oriëntatie en farao Echnaton’ (Computable, 11 mei), maar moet ik zijn vragen wel instemmend beantwoorden.
Van der Lans stelt in de vorm van vragen het volgende:
1) object-oriëntatie is te complex voor de gemiddelde programmeur;
2) leidt tot zeer lastig te onderhouden software;
3) het wordt niets met object-oriëntatie.
Volgens mij zijn oo-concepten inderdaad lastiger onder de knie te krijgen dan bij de traditionele rechttoe-rechtaan procedurele benadering. Echter, de gemiddelde programmeur van nu is heel goed mogelijk de bovengemiddelde programmeur van morgen! Het objectgeoriënteerde leerproces duurt langer dan om traditioneel programmeren aan te leren. Per slot van rekening maakt het leren programmeren slechts een klein deel uit van het gehele currriculum.
De grote ophef rondom .Net Visual Basic is overigens voornamelijk het gevolg van de aankondiging dat het niet compatibel zal zijn met de oudere VB versies. Als alle nieuwe extensies de bestaande programmatuur intact hadden gelaten, was er geen vuiltje aan de lucht geweest.
Manke programmeurs
De tweede vraag moet ik ook al met ja beantwoorden! Als programmeurs concepten en gereedschappen toepassen die hun begrip te boven gaan, dan schieten zij zich vanzelf in de voet, het project loopt daarna mank, de programmeurs schieten zich vervolgens in hun andere voet, en het project valt om. Inderdaad erg lastig. Mijns inziens is de stelling achter de vraag daarentegen geheel incorrect! Mijn tegen-argumentatie is als volgt.
Object-oriëntatie leidt niet tot zeer lastig te onderhouden software, want oo leidt tot beter te onderhouden software!
Je reinste paradox, niet? Soms wordt er mij een oplossing voor een probleem gevraagd door een collega. En als ik dan terloops eerst opmerk, dat de oplossing heel simpel is, wordt soms ad rem gereageerd met de opmerking "Ja! Het is simpel als je het weet!", maar ook met "Nee! Het is juist moeilijk, anders had ik het zelf wel geweten!" Aldus paradoxaal, maar waar!
Een van de belangrijkste doelstellingen van oo is ‘continuïteit’ of ‘naadloosheid’ in de overgang van het probleemdomein naar de programmatuur die een oplossing biedt. Als Van der Lans ervaren heeft dat de toepassing van oo tot onoverzichtelijke relaties heeft geleid, dan is er misschien ook een plausibele(re) verklaring te vinden in de wijze waarop oo is toegepast, of beter gezegd, de pogingen daartoe. Deze laatste opmerking is niet denigrerend bedoeld. Ik wil hiermee alleen benadrukken dat het resultaat van elke onderneming niet alleen afhankelijk is van het gereedschap, maar ook van de hanteerders.
Bovenstaande beschuldiging is natuurlijk makkelijk gemaakt. Gewoon beweren dat het niet goed is uitgevoerd. Of dat zo is weet ik natuurlijk niet, maar de voorbeelden van Van der Lans zijn in ieder geval niet steekhoudend.
Herbruikbare code
Herbruikbaarheid van code door overerving is niet de essentie van Oop. Als het dat was, wat is dan nog het feitelijke verschil met de traditionele code-bibliotheken? In Java en C# is het bijvoorbeeld mogelijk om een zogenaamde ‘interface’ te definiëren, en deze bevat geheel geen code! De essentie van een interface is het programmeren per contract. Voor Oop is dit belangrijker dan overerving van de implementatiecode.
Het programmeren per contract is juist bedoeld om relaties en afhankelijkheden expliciet te maken. Elke klasse-implementatie die zich gebonden heeft aan een dergelijk contract, mag hier nimmer van afwijken. Dit geeft de programmeur duidelijkheid en zekerheid. De suggestie dat met
Oop het aantal onderlinge afhankelijkheden juist groter wordt, is een beetje flauw. Ik zou zelf willen stellen dat elke (vermeende) oo-implementatie die er niet in slaagt om adequaat rekening te houden met alle historische verworvenheden van de software ontwikkelingsdiscipline (information hiding, low coupling, high cohesion, structured programming, abstracte datatypes, enzovoort), simpelweg geen object-oriëntatie is! En tevens ook in een traditionele context niet door de beugel kan!
Oop levert daarnaast niet per se meer compacte code op. Met talen als Visual Basic, Pascal of C (bijvoorbeeld X-windows) kan men in principe ook oo-concepten toepassen. En ‘overriding’ is essentiëler dan ‘overloading’.
Gezond verstand
Het laatste voorbeeld is die van het ontbreken van complexiteit in klassieke administratieve systemen. Zeker zal in een oo-project meer de nadruk liggen op een gedegen voorbereiding. Maar het gaat evenzogoed om het gebruik van gezond verstand. De uitdaging is hier niet zozeer de toegepaste methodiek of techniek, maar eerder het correct inschatten van een project, de juiste afwegingen maken en zelfdiscipline tonen (want je hebt in principe geen oo nodig om jezelf en anderen in de voeten te schieten). Als er onverhoopt toch een verkeerde keuze is gemaakt, ‘Het zij zo’. Door schade en schande (‘hoe het niet moet’, ‘anti-patterns’) word je ook wijzer.
Ook de derde vraag kan ik met ja beantwoorden. Misschien zitten wij inderdaad in een Echnatonse periode, een doodlopende straat. Maar wat betekent dat nu eigenlijk? Tegenwoordig komt monotheïsme het meest voor; had Echnaton dan toch meer gelijk?
Die doodlopende straat is dat niet te vergelijken met de huidige ‘state of the art’ en alle ontwikkelingen die daaraan zijn voorafgegaan? We maken immers vooruitgang door met horten en stoten de ene na de andere barrière te slechten.
‘Gemiddelde’ programmeurs moeten niet al hun kruit verschieten door objectgeoriënteerde concepten te negeren, laat staan vermijden. Wees alleen een beetje terughoudend en schiet niet met een kanon op een mug!
Wen Hu Delft
Het boek ‘Design Patterns’ van Gamma et al. is een echte aanrader voor de willekeurige programmeur die geïnteresseerd is in Oop. Alleen al de inleiding van het boek slaagt er uitstekend in om de waarde en het praktisch nut van objectgeoriënteerde concepten duidelijk te maken.
