Een enorm succes in de hardware-industrie is het principe van herbruikbare componenten in de vorm van lsi-circuits (large-scale integration) in standaardcomponenten als microprocessoren, schijfcontrollers en videocontrollers. Het wordt hoog tijd dat de software-industrie de kop uit het zand haalt en iets vergelijkbaars realiseert.
Hardwarecomponenten zijn alleen herbruikbaar op ontwerpniveau, terwijl softwarecomponenten in theorie dynamisch op nieuw te gebruiken zijn. Denk bijvoorbeeld aan een validatiecomponent die tegelijkertijd door meerdere applicaties wordt gebruikt. De software-industrie heeft zich de afgelopen jaren beziggehouden met het concept van object-oriëntatie. Dat concept voert herbruikbaarheid nog een stap verder: naast encapsulatie zijn ook overerving en polymorfisme mogelijk, terwijl bij hardwarecomponenten alleen encapsulatie mogelijk is.
Herbruikbare softwarecomponenten hoeven geen objecten in enge zin te zijn. Applicaties kunnen ook subroutines en systeemfuncties, zoals bestandssystemen en databases, als componenten zien. Het probleem met subroutines is echter dat compilers slimme foefjes hebben ingebouwd, zoals meerdere toegangspunten en toegang tot externe variabelen. Soms maakt de compiler variabelen binnen een subroutine zichtbaar voor andere routines. Dit betekent dat er een onderlinge afhankelijkheid ontstaat tussen subroutines en de programma’s die ze aanroepen (gemeenschappelijk geheugen bijvoorbeeld). Dat belemmert de herbruikbaarheid. Voor een herbruikbare subroutine is discipline nodig: er mag maar één toegangspunt zijn, parameters mogen alleen worden doorgegeven bij de aanroep en er mogen geen referenties zijn naar externe gegevens. Dat is allemaal mogelijk, maar wordt in de praktijk zelden afgedwongen. Merk op dat we een Cics/Cobol-routine als herbruikbare component kunnen zien, al kent deze, net als zijn hardware-tegenhanger, geen polymorfisme en overerving. De parallel met de hardwarewereld zou voldoende bewijs moeten leveren voor het vermoeden dat encapsulatie te gebruiken valt om van een systeem de kosten te verlagen, de ontwikkeltijd te verkorten en de betrouwbaarheid te verbeteren. Ik kan voor overerving geen vergelijkbare analogie bedenken, al geloof ik wel dat het een belangrijke verbetering in software-engineering betekent. Ik denk echter dat we niet hoeven te wachten op puristische objectsystemen voordat we gaan nadenken over herbruikbaarheid. Het inpakken van schone conventionele codemodules als herbruikbare componenten is dus een goed idee. Denk daarbij aan OLE-controls of Cics/Corba-ontwikkelingen. Zelfs als object-oriëntatie volwassen wordt, zullen deze componenten een nuttig en productief leven hebben. OLE is minder goed dan SOM/Corba, maar er zijn talloos veel OLE-componenten en slechts weinig SOM-equivalenten. Zonder applicaties mislukt zelfs het beste systeem, net als bij de Betamax-videostandaard.
Als we nadenken over componenten aan de kant van de gebruiker (de front end), moeten we ons realiseren dat OLE nu geen concurrentie ondervindt van SOM, maar van Java Beans Frameworks. Stel dat dit raamwerk aan populariteit wint en wordt ondersteund met door gebruikers ontwikkelde Java-applets en standaard Java-componentbibliotheken. Dan zal het superieur zijn aan OLE en het verschrikkelijke Activex. Het biedt namelijk een omgeving die op alle systemen kan draaien, inclusief netwerkcomputers, waarbij objecten op een gedistribueerde manier worden ondersteund. Beschikbaarheid van applicaties is hierbij van essentieel belang. Voordat gebruikers Java Beans zullen accepteren, moeten de applicaties aantonen dat ze significant beter zijn dan toepassingen op basis van OLE plus uitbreidingen.
Door OLE en Java is er nu veel activiteit aan het gui-front. Er bestaan vele OLE-controls en er zijn een heleboel geruchten over enorme investeringen in Java Beans, die overigens nog niet gereed zijn. Daarmee zal de ontwikkeling van client-software mogelijk zijn. Er zijn controls en Java-ontwikkelingen waarmee dikke PC-clients databases op de server kunnen benaderen (Odbc en Jdbc). Dikke clients introduceren echter weer een legacy-probleem. Om te kunnen overstappen op het dunne client-model blijven gui-clients nodig, maar server-componenten worden steeds belangrijker. Er zijn altijd al vraagtekens gezet bij het zuivere objectmodel voor gegevensafhandeling. De meeste transactiegegevens zullen niet worden opgeslagen in een objectdatabase, maar in een relationele database. Een bedrijfsobject op de server zou deze gegevens moeten encapsuleren. Dat introduceert echter weer een compatibiliteitsprobleem. Als we de overerving even vergeten, is een goed ontworpen routine in Cics/Cobol of Tuxedo/Java te encapsuleren en herbruikbaar te maken via een standaard interface, zoals Corba of Dole. De huidige component-tools zijn te gebruiken om code voor een dunne client te ontwikkelen. Daarmee wordt toegang verkregen tot robuustere transactieroutines alsof het client-componenten waren.
De laatste les die we van de hardwarewereld kunnen leren is het belang van documentatie. Herbruikbare componenten moeten niet alleen beschikbaar, maar ook strikt gedocumenteerd zijn. Voor de meeste softwarecomponenten geldt dit helaas niet.
