Objecten en componenten zijn weliswaar nauw met elkaar verbonden, maar zeker niet identiek. Belangrijke kenmerken van het objectmodel zijn encapsulatie, overerving en polymorfisme.
Deze karakteristieken zijn in meer of mindere mate beschikbaar in programmeertalen als Smalltalk en Java, of ze worden toegevoegd aan bestaande procedurele talen, zoals in het geval van C++ en Object Cobol. Ze worden op verschillende manieren geïmplementeerd; soms is de runtime-omgeving objectgeoriënteerd, maar vaker wordt objectoriëntatie gebruikt in de vorm van klassebibliotheken, waarmee een volledige, op zich zelf staande objectcode wordt gebouwd.
Het gaat hierbij vooral om herbruikbaarheid: de mogelijkheid om applicaties te bouwen met behulp van bestaande componenten, zonder dat je elke keer opnieuw hoeft te beginnen. In het objectmodel maakt encapsulatie herbruikbaarheid mogelijk, maar wat voegen overerving en polymorfisme hier aan toe? Deze vraag blijkt niet eenvoudig te beantwoorden. Er zijn veel eenvoudiger manieren om herbruikbare componenten te bouwen. Een voorbeeld is het inpakken van op zichzelf staande modules van oudere systemen, zoals Cics-transacties.
Laten we eens kijken naar een analogie in de hardware-wereld. Jaren geleden werden herbruikbare componenten in de hardware-wereld geïntroduceerd in de vorm van geïntegreerde circuits (IC’s). De hardware van tegenwoordig wordt gebouwd met microprocessoren, geheugenchips, controllers en dergelijke. De functionaliteit van deze componenten is nauwkeurig gedefinieerd; hardware-ontwerpers moeten zich aan de regels houden. Alleen bij speciale Asics heeft de hardware-ontwerper enige vrijheid in het vaststellen van de functionaliteit van een IC, en zelfs deze componenten zijn opgebouwd uit standaardcomponenten uit speciale bibliotheken.
In de hardware-industrie is het gebruik van componenten een enorm succes gebleken. De verbeteringen in prijs en prestatie zijn astronomisch, en dat geldt ook voor de betrouwbaarheid. Software staat hiermee in een treurig contrast. Het is bijna een schande dat gebruikers het tegenwoordig heel gewoon vinden dat software veelvuldig crasht, terwijl de hardware ultra-betrouwbaar is. Waarom worden de hardware-lessen niet in software toegepast? Dat is een lastige vraag die ik niet zal proberen te beantwoorden. De tijd is rijp om verder te kijken; software-componenten zijn op middellange termijn dé manier om software te verbeteren.
Mocht u de analogie tussen hardware en software hebben gemist: IC’s maken gebruik van encapsulatie en zijn daardoor herbruikbaar, maar overerving en polymorfisme kennen ze niet. Ik heb lang nagedacht over een analogie in een ander vakgebied om het nut van overerving duidelijk te maken, maar helaas. Theoretische voordelen worden tenietgedaan door een toegenomen complexiteit, behalve op programmeerniveau. Wat we nodig hebben, zijn software-componenten met nauwkeurig gedefinieerde invoerfuncties en duidelijk gespecificeerde reacties op geldige invoerwaarden.
Het pure objectmodel van Open Doc leek lange tijd aantrekkelijk in vergelijking met het componentmodel van OLE. Ook ik was een aanhanger van Open Doc, maar ik had het mis. De eenvoud en de beperkingen van OLE zijn juist grote voordelen. Het was heel eenvoudig om bibliotheken met OLE-componenten te maken, die gemakkelijk konden worden hergebruikt. Open Doc was zo geavanceerd dat niemand er ooit een eindproduct mee gebouwd heeft!
We kunnen veel verder terug gaan dan OLE om te zien hoe componenten gebruikt hadden kunnen worden. Een TP-monitor zoals Cics of Tuxedo is een goed raamwerk voor componenten. Applicaties kunnen worden ontwikkeld als Cics- of Tuxedo-modules, die na grondige specificatie als herbruikbare componenten te gebruiken zijn. Dat dit in de praktijk niet gebeurde, kwam doordat de prestatie in die dagen een groot probleem was en het aanroepen van Cics de nodige overhead met zich meebracht. Dit leidde ertoe dat programmeurs modules samenvoegden tot grote transacties en andere trucs toepasten om de prestatie te verbeteren, zoals het gebruik van een gemeenschappelijk geheugen – een zware overtreding in het componentenmodel. Maar tegenwoordig is hardware goedkoop en is prestatie nauwelijks meer een punt. Goed ontworpen transactiecomponenten kunnen de voordelen – die we kennen uit de gui-wereld – ook aan de serverkant brengen. Helaas zijn er maar bedroevend weinig systemen gebouwd met componenten op basis van conventionele systemen.
De conclusie luidt dat de aandacht gericht moet zijn op encapsulatie en herbruikbaarheid. Hetzij met tools die zulks afdwingen (zoals Enterprise Java Beans), hetzij door een strikte discipline bij het gebruik van meer conventionele tools. Vergeet object-oriëntatie op het abstracte niveau van applicatieontwikkeling; het is meer iets voor het harde programmeerwerk.
