"Objectgeoriënteerd programmeren of bouwen met componenten is helemaal niet zo efficiënt als altijd wordt gesteld. De paradigma’s gaan er fundamenteel van uit dat de wereld bestaat uit disjuncte objecten. In de meeste gevallen is dat echter niet zo", meent Rob Ronda. Hij bepleit een nieuw paradigma: dat van het conceptueel georiënteerd ontwikkelen.
Stel je wilt niet een programma schrijven, maar de generator voor dat programma. Je zou dan kunnen denken aan een vierde-generatie taal (4gl). Dit begrip verwijst naar een taal waarmee code in derde-generatie talen, traditionelere talen als C en Pascal, wordt gerealiseerd. Een 4gl is daarmee abstracter dan een 3gl, en daardoor krachtiger, en vormt een domein waarin de generator voor een programma gerealiseerd zou kunnen worden.
Een 4gl is een formele taal. Die bakent twee domeinen af. Het domein van de werkelijkheid dat door de taal beschreven kan worden, en het domein van de werkelijkheid dat niet door de taal beschreven kan worden.
Dit is tevens de kern van het probleem met 4gl-talen of tools. Alles dat binnen hun uitdrukkingskracht valt, is sneller, efficiënter en met minder fouten te realiseren. Dit is de beoogde winst bij het gebruik van 4gl. Vaak blijkt dat die winst deels te niet wordt gedaan door zaken die niet te beschrijven zijn met deze taal. Het 4gl-tool is dus niet efficiënt, ondanks het feit dat het tool meer kan dan voorheen. Omdat de oorspronkelijke doelstelling van efficiëntie feitelijk niet is bereikt, is het oorspronkelijke probleem weer terug.
Ik heb daarom de neiging om niet over 4gl te praten, maar over methodiek en nog liever over formele methodieken. In een vorige artikel (Kennis van modellen ontbreekt; Computable, 28 februari) heb ik het belang van het model van de te ontwikkelen applicatie al aangegeven. Het model is expliciet, en op basis van de interpretatie van een model kunnen generatoren worden gemaakt, die de interpretatie implementeren, dus de applicatie maken. Die generatoren hebben dezelfde nare eigenschap als 4gl-talen. Je snelt op de niet uit te drukken werkelijkheid af met de snelheid van het licht. Voor je het weet, kun je wéér niet voldoen. Ik ga daarom ook niet uit van dé generator, hét tool. De methodiek houdt juist rekening met het feit dat de generator nooit volledig is. Rond de generator is een team van mensen nodig. Deze zorgen ervoor dat de beperkingen van het model worden gesignaleerd. Binnen de methodiek is ruimte om het model aan te passen – en zo de generatoren. Wat eerst buiten de uitdrukkingskracht valt, ligt er later in. Zolang het er niet in zit, is de implementatie duur. Zit het er wel in, dan is de implementatie goedkoop, betrouwbaar en efficiënt. Men ziet direct wanneer een behoefte niet in het model past, en dus ook of er een duur traject aankomt. Deze werkwijze noem ik ’team 4gl’.
Conceptueel georiënteerd
‘Team 4gl’ is de motor van de methode van het nieuwe paradigma. De geest ervan noem ik ‘conceptueel georiënteerd ontwikkelen’. Het model van een applicatie bestaat uit de essentiële aspecten van een applicatie, de ‘concepten’. De concepten en hun onderlinge verbanden worden in het model gerepresenteerd. In generatoren wordt de interpretatie van concepten en verbanden gerealiseerd. Het vastleggen van het model in termen van de instructies van de abstracte machine of ‘syntactische suiker’ is het model van de applicatie. Uitvoeren van het model van de applicatie leidt tot het genereren van de applicatie, en dus tot het concrete opgeleverde product.
De centrale vraag is ‘Hoe ontdekt men de concepten?’. Dat is een oorzakelijk gevolg van objectgeoriënteerd denken, dat de werkelijkheid afbakent via disjuncte objecten. Maar de werkelijkheid laat zich niet modelleren in termen van disjuncte objecten. Bij nadere bestudering van objectgeoriënteerde code blijkt, dat de code die de niet disjuncte werkelijkheid representeert, verspreid is over de methoden (‘methods’) van de objecten. Heeft men goed gestructureerd geprogrammeerd, zijn de methoden van verschillende objectklassen uniform benoemd om uitdrukking te geven aan de verspreide functionaliteit? In Java is zelfs een taal-construct beschikbaar waarin men dit kan objectiveren, de ‘interface’. Deze is in essentie een object over functionaliteit, terwijl klasse (class) een object binnen data omvat.
Concepten zijn slechts te vinden en relevant indien iets meerdere malen gerealiseerd moet worden. Dat is niet absoluut, want conceptualiseren impliceert classificeren. Nog niet geschreven applicaties die geheel of gedeeltelijk binnen een klasse vallen, hoeven niet geheel opnieuw gebouwd te worden. Alleen dat deel dat buiten de klasse valt. Door op inzichtelijke wijze volgens de traditionele lijnen te ontwikkelen, zijn de concepten af te leiden met behulp van klassen en interfaces. Dit proces duid ik aan met ‘conceptueel georiënteerd ontwikkelen’.
Arbitraire keuze
Voor een dergelijke manier van werken, gelden heel andere regels.
Objectgeoriënteerd programmeren of bouwen met componenten is helemaal niet zo efficiënt als altijd wordt gesteld. De paradigma’s gaan er fundamenteel van uit dat de wereld bestaat uit disjuncte objecten. In de meeste gevallen is dat echter niet zo. De implementatie met objectgeoriënteerde technieken blijkt uiterst dan inefficiënt. In die gevallen kan polymorphie zelfs ronduit gevaarlijk zijn.
Door het gebruik van generatoren is het gestructureerd programmeren, modulair programmeren, objectgeoriënteerd programmeren een arbitraire keuze geworden. Verstandig om te doen, maar niet noodzakelijk. In voorkomende gevallen moet je het niet doen, of is het zelfs onmogelijk. Let wel: met generatoren hoeft men zich niet te beperken tot de grens van een programmeeromgeving. Wat let je om geheel ‘dedicated’ Linux te genereren, te compileren, scripts aan te maken, enzovoort, en zo je applicatie op een compleet lege machine te genereren. Er zullen situaties zijn, waarin gestructureerd werken even niet kan.
Op het gebied van de infrastructuur zijn client/server, multitier, en meer van dergelijke zaken alleen noodzakelijk om de handmatige bouw en het beheer makkelijker en betrouwbaarder te maken. Maar dat kan ook via generatoren, en dan geldt opnieuw: wellicht verstandig maar zeker niet noodzakelijk.
De hierboven geformuleerde gedachten verwijzen mijns inziens naar een heel andere manier van software ontwikkelen. Het is moeilijk om dit aan vakgenoten duidelijk te maken, omdat er in voorkomende gevallen een bedreiging in de aanpak schuilt. Het is ook moeilijk om commercieel te verwoorden, omdat de voorwaarden waaronder wij systemen kunnen leveren -maatwerk én fixed price én ‘no cure, no pay’- gewoonweg niet geloofd worden. Dit alles is in Nederland bedacht, en wordt aldaar op de markt gezet. Dus zeg niet dat ‘we’ technieken, methoden en software overwegend uit het buitenland halen.
Rob Ronda, Imda