Herbruikbare software-componenten worden al geruime tijd gebruikt in combinatie met conventionele 3GL-technologie. De problematiek rond standaarden is hierbij echter nooit bevredigend aangepakt. De programmeur kan alle toeters en bellen van een 3GL-compiler gebruiken en daarbij over en weer refereren aan codemodules, waarbij de spelregels van herbruikbaarheid met voeten worden getreden.
Herbruikbaarheid is op verschillende niveaus toe te passen. Zo kunnen programmeurs software-componenten gebruiken bij het ontwikkelen van modules; modules kunnen op hun beurt ook herbruikbaar zijn, maar op een hoger niveau van functionaliteit wordt een module minder flexibel en dus moeilijker opnieuw te gebruiken.
Componenten zijn ook tijdens de executie van een programma te gebruiken, waardoor de flexibiliteit toeneemt maar de prestatie minder wordt. Hiervoor is ook een ‘run-time’ uitbreiding van het besturingssysteem nodig, die meestal leveranciersspecifiek zijn, zoals Microsoft Ole in Windows NT, of Cics op een MVS-mainframe.
Een standaard zou de voorkeur hebben omdat herbruikbaarheid hand in hand gaat met portabiliteit tussen verschillende platforms. Helaas is de IT-industrie niet dol op standaarden, getuige de mislukking van Opendoc, een standaard die weliswaar veel geavanceerder en adequater is dan Ole, maar die in de markt door geen enkele applicatie wordt ondersteund.
Standaard run-time omgevingen hebben een enorme impuls gekregen door de virtuele Java-machine die tegenwoordig op alle platforms beschikbaar is. In de meeste gevallen is Java onderdeel van de webbrowser, Netscape Navigator dan wel Internet Explorer, maar Java wordt steeds vaker geïmplementeerd in databases (Oracle) en besturingssystemen (Solaris, OS/2 en binnenkort ook MVS, OS/400 en andere Unix-systemen).
Microsoft zal geen virtuele Java-machine (JVM) ondersteunen omdat deze vergelijkbaar is met de leveranciersspecifieke Ole-uitbreidingen die iedereen kent als Activex. Toch kan één systeem te beperkt blijken; concurrentie is zo slecht nog niet en zal leiden tot een verbetering van zowel Activex (op de PC) als JVM (op alle machines). De afgelopen jaren hebben we helemaal niet kunnen kiezen, en dit is de belangrijkste reden voor de armzalige kwaliteit van onze huidige applicaties.
Objecten kunnen overigens best zijn opgebouwd uit kleinere componenten; zo kunnen Java Applets worden samengesteld uit Java Beans, zodat het eenvoudige componentmodel en object-oriëntatie elkaar niet bijten. Aan de andere kant zijn componenten te gebruiken in systemen die niet objectgeoriënteerd zijn; Ole-controls (OCX) zijn een belangrijk voorbeeld van componenten die kunnen worden gebruikt door niet-objectgeoriënteerde programmeertechnieken, zoals Visualbasic. Ook bibliotheken met objectklassen zoals die worden gebruikt in C++ kunnen procedurele code bevatten en zijn daarmee slechts gedeeltelijk objectgeoriënteerd.
In het ideale geval ondersteunt objecttechnologie drie belangrijke principes: encapsulatie, overerving en polymorfisme. Vooral encapsulatie maakt herbruikbaarheid op componentniveau mogelijk; er is maar weinig bewijs waaruit blijkt dat overerving en polymorfisme werkelijk van waarde zijn (al denk ik dat dat op lange termijn wel zo is).
Microsoft heeft het prima gedaan met Ole, een encapsulatietechniek, en is nu pas aan overerving toe. Een nog sterkere analogie is het fantastische succes dat de hardware-industrie heeft gehad met geïntegreerde circuits zoals microprocessoren, geheugen, controllers en dergelijke. Dit heeft alles te maken met encapsulatie en herbruikbaarheid, maar niets met overerving of polymorfisme. Ik zie voorlopig nog geen einde komen aan het debat over welke vorm van object-oriëntatie de beste is, pure objecttechnologie of eenvoudige herbruikbaarheid, maar ik denk dat de eerste het op de lange termijn zal winnen. Microsoft zal Activex op den duur wel volledig object-georiënteerd maken.
Het ziet er nu naar uit dat er drie componenttechnologieën zullen ontstaan. Ole-controls (OCX) behoren nu al tot de gevestigde orde. C++-klassebibliotheken zijn ook krachtig. De derde kandidaat is Java Beans, niet zo krachtig als C++, maar sterk in opkomst nu Sun, Microsoft, Symantec en dergelijke de lucratieve markt voor Java-ontwikkeling aan het ontginnen zijn.
De academische ondersteuning van Java, de objectgeoriënteerde taal waar iedereen op heeft zitten wachten, zal ervoor zorgen dat Java snel volwassen wordt en C++ de komende twee tot drie jaar zal verdringen (behalve voor specialistische systeemprogrammering).
Smalltalk, Eiffel en andere objecttalen zullen op een zijspoor belanden, simpelweg omdat Java als anti-Microsoft-wapen het gewicht van een hele industrie achter zich heeft. Zelfs Visualbasic staat onder druk.
De presentatiekant is het best gebaat bij OCX en een groeiend aantal Java Beans. C++-klassebibliotheken zijn goed voor speciale applicaties, inclusief grafische gebruikers-interfaces voor Unix; er zijn C++-libraries die eenvoudig gepoort kunnen worden tussen Windows, Mac, OS/2, Unix en dergelijke.
Objecten aan de serverkant zijn relatief onvolwassen of bestaan zelfs nog niet. Het onjuiste gebruik van het dikke client-model heeft de ontwikkeling ervan vertraagd. De echte strijd zal zich nu gaan afspelen rond de server, niet rond de client. Ik verwacht daarom een snelle vooruitgang.
