Componenten: Revolutie, evolutie, of devolutie? door Bart Huylebroeck

Transcriptie

1 Componenten: Revolutie, evolutie, of devolutie? door Bart Huylebroeck Promotor: Frans Arickx Serge Demeyer Medelezer: Jan Broeckhove Abstract: Aan de hand van een aantal boeken wordt eerst gezocht naar een werkbare definitie van het begrip component. Daarna wordt nagegaan waarin het component-georienteerde paradigma verschilt van andere gangbare paradigma s, zowel in theorie als in praktijk. Uiteindelijk is het besluit dat hoewel er geen duidelijke scheidingslijn bestaat, het componentgeorienteerd paradigma toch genoeg nieuwe aspecten aan programmeren toevoegt om effectief van een paradigma te spreken

2 0 Inhoud 1 Definitie 1.0 Analogie 1.1 Clemens Szyperski 1.2 Bertrand Meyer 1.3 Bruce Powel Douglass 1.4 Siemens Gang of Five 1.5 Andere 1.6 Kenmerken van componenten 2 Distinctie 2.1 Object-Oriented programming 2.2 Aspect-Oriented Programming [XEROX] 2.3 Patterns Onstaan Definitie Toepassing 3 Eigenschappen en beloften 3.1 Correctness (correctheid) 3.2 Reliability (betrouwbaarheid) 3.3 Interoperability/compatibility (samenstelbaarheid) 3.4 Efficiency/performance (efficientie) 3.5 Testability/verifiability (verifieerbaarheid) 3.6 Reusability (herbruikbaarheid) 3.7 Changeability (veranderbaarheid) 3.8 User friendliness/ease of use (gebruiksvriendelijkheid) 3.9 Understandability (eenvoud) 3.10 Productivity (productiviteit) 3.11 Timeliness (tijdigheid) 3.12 Visibility (transparantie) 4 Huidige situatie 4.1 Besturingssystemen 4.2 Plug-in architecturen 4.3 Visual Basic 4.4 CORBA/OMA Overerving en hergebruik Versioning Management van Objecten Persistence Interoperabiliteit Huidig gebruik

3 4.5 COM/DCOM/COM Overerving en hergebruik Versioning Management van Objecten Persistence Interoperabiliteit Huidig gebruik 4.6 JavaBeans Overerving en hergebruik Versioning Management van Objecten Persistence Interoperabiliteit Huidig gebruik 5 Verlanglijstje 5.1 Taal Toevoegen van keywords Aspect-orientatie Componenten als threads 5.2 Contract Pre- en postcondities Niet-functionele vereisten Wettelijke aansprakelijkheid 6 Magic: the Gathering 6.1 Het spel 6.2 De software 6.3 Code hergebruik 6.4 Combineren van kaarten 6.5 Een alternatieve methode 7 Conclusie 8 Referenties

4 1 Definitie Het begrip "component" bestaat al tientallen jaren, al van zodra het begrip "reuse" in gebruik kwam. Toch is het nog steeds nuttig om stil te staan bij de exacte definitie van de term. Vergelijking van verschillende auteurs en teksten zal duidelijk maken dat een "component" een zeer rekbaar begrip is, zelfs al zijn er duidelijke overeenkomsten. 1.0 Analogie Programmeurs streven ernaar, net zoals iedereen, om hun job zo eenvoudig mogelijk te maken. Daarbij lonken ze graag naar beproefde technieken in verwante beroepstakken, zoals de wereld van electronische componenten. In het ideale geval zou software engineering sterk te vergelijken moeten zijn met "electrical engineering", waar een nieuw systeem bouwen dikwijls voor een groot deel bestaat uit bestaande componenten selecteren en verbinden met elkaar. Zo ook streven software ontwerpers ernaar om programmeren zoveel mogelijk te reduceren tot het combineren van bestaande software onderdelen. Daarom wordt de code die software componenten met elkaar verbindt al graag eens "wiring" genoemd. De vergelijking gaat natuurlijk nooit helemaal op. Bertrand Meyer en Szyperski zijn het eens dat software engineering verschilt van de andere engineering disciplines in een zeer fundamenteel opzicht: het onderscheid tussen ontwerp en product is veel vager. Het verschil tussen een tekening op papier, en de betonnen brug is vrij duidelijk: van het een kan je vallen, van het andere niet [SDM][SZYP, p.8]. Bij software engineering rijst dikwijls de vraag of een bepaalde keuze nu een kwestie van design of implementatie is. Dat vage onderscheid laat zich in verschillende kleine dingen voelen. Hoe dikwijls wordt een algoritme/procedure/handeling niet uitgelegd in pseudo-code? Hoe verleidelijk is het niet om zelf "in de code te duiken" om te weten te komen wat het precies doet? Een tweede punt waar de vergelijking mank zou kunnen lopen is de "wiring". Het woord zelf suggereert zeer eenvoudige verbindingen tussen de verschillende componenten, ongeveer zoals een geleidende draad wordt getrokken tussen twee poorten van electronische chips, of zoals cement de muur met de steunpilaar verbindt. In praktijk zou dat bij software wel eens tegen kunnen vallen. Sommige triviale dingen kunnen inderdaad zeer eenvoudig beschreven worden: in de Java beanbox bijvoorbeeld, is het mogelijk om een knop te "verbinden" met een animatie-bean op zeer intuitieve wijze, waarna de animatie kan gestart of gestopt worden met een druk op de knop. Zulke simpele en triviale verbindingen zullen jammer genoeg geen meerderheid uitmaken bij composities van componenten. Hoe leg je bijvoorbeeld vast dat enkele welbepaalde rijen cellen uit een

5 spreadsheet component integraal naar het database component moeten overgebracht worden, waar ze in een nieuwe database moet gestoken worden en bovendien enkele velden met geaggregeerde informatie (bijvoorbeeld een meetkundig gemiddelde) moeten worden gevuld? Drag-and-drop zal hier een beetje tekort schieten. Volgende delen gaan ietsje dieper in op de visies van enkele auteurs. 1.1 Clemens Szyperski Szyperski [SZYP] definieert een component als volgt: - A component is a unit of independent deployment. - A component is a unit of third-party composition. - A component has no persistent state. independent deployment Met "unit of deployment" worden verschillende dingen aangestipt. Ten eerste worden componenten in contrast gesteld met syntactische eenheden, zoals de klasse, of een enkele functie. Componenten kunnen verschillende objecten en procedures omvatten, zodat ze de grenzen kunnen overschrijden zoals die door een programmeertaal zijn vastgelegd. Toch vormt een component een duidelijke eenheid: het is een zeer duidelijk afgelijnd geheel, dat ofwel helemaal, ofwel helemaal niet wordt gebruikt. De interface naar "buiten" toe wordt zeer duidelijk vastgelegd, maar voor de rest geldt het component als een black box. Het woord "deployment" duidt op nog een tweede verschil met klassiekere "units of reuse": een component wordt niet gecompileerd, het wordt "deployed", dat wil zeggen het component wordt toegevoegd aan een draaiend systeem, op run-time. Dit wil ook zeggen dat een component niet wordt herbruikt als source-code, maar eerder in binaire vorm. Dit wordt erg benadrukt door Szyperski, en in columns [SDM] gaat hij iets dieper in op de noodzaak om binaire componenten te gebruiken, zodat ze op run-time niveau kunnen worden samengesteld. Indien noodzakelijk, kunnen zo zelfs systemen ontworpen worden met "hot-swapping". Dit is in sterk contrast met andere vormen van hergebruik, dat meestal op source-niveau gebeurt. "Independent" duidt op de sterke inkapsulatie. Om herbruikbaar te zijn in zeer verschillende omstandigheden, moet een component op zichzelf staan, en liefst niet te veel "verbindingen" hebben met die omgeving. Een kleine analogie: een levertransplantatie is veel moeilijker dan een harttransplantatie, enkel omdat de lever meer verbindingen heeft dan het hart. Bij componenten wordt er dus naar gestreefd om de "coupling" zo laag mogelijk te houden. Afhankelijkheden kunnen natuurlijk nooit helemaal vermeden worden. Het doel van componenten is immers om ze te combineren. Als een component dus op bepaalde

6 andere soorten componenten (services) rekent, moeten deze afhankelijkheden zo duidelijk, uniform en formeel mogelijk worden beschreven. Hierover later meer. third-party composition Dit heeft veel te maken met de droom van willekeurig combineerbare elementen, en het is dan ook het streefdoel voor component-georienteerde ontwikkeling. Componenten worden dan producten, die verkocht worden aan andere ontwikkelaars, die ze dan kunnen inzetten in hun software oplossing. Deze "derde partij" moet niet noodzakelijk een ander bedrijf zijn; het kan gaan om een ander departement binnen hetzelfde bedrijf, of zelfs gewoon een andere programmeur aan hetzelfde project. Bij elk software project rijst de vraag of een bepaald stuk intern moet worden ontwikkeld, of dat er bestaande software wordt gekocht. Interne ontwikkeling heeft als voordeel dat de software zeer sterk zal aangepast zijn aan de specifieke behoeften van het bedrijf, maar het brengt een vrij hoge ontwikkelingskost met zich mee, en ook een aanzienlijk risico, zowel financieel als op gebied van scheduling. Bovendien is er altijd de kans dat het warm water opnieuw wordt uitgevonden of dat de behoeften verkeerd werden ingeschat of ondertussen al geevolueerd zijn. Het kopen van bestaande software heeft als grote voordeel dat ze veel vlugger beschikbaar is, dat de aankoopprijs bekend is, en dat het onderhoud dikwijls wordt overgelaten aan de oorspronkelijke ontwikkelaar van de software. Nadeel is dat de software zelden voor 100% aan de wensen zal voldoen. En het wordt er ook niet makkelijker op om een voorsprong op de concurrenten te behouden, als de werking van het bedrijf afhangt van een product dat vrij verkrijgbaar is op de markt. persistent state Szyperski benadrukt ten stelligste dat een component geen "state" mag hebben [SZYP][SDM]. De redenering is dat als componenten zich in een bepaalde toestand kunnen bevinden, dan kunnen ze niet vrijelijk worden vervangen, of in een nieuw systeem worden ingebouwd. Het vervangende object kan niet garanderen dat het zich in dezelfde toestand bevindt, en zal dus verschillend reageren. Dit klonk me allemaal nogal verwarrend in de oren, en ik ben dus verder beginnen graven naar wat Szyperski hiermee juist bedoelt. Globale variabelen worden taboe verklaard, samen met elke constructie die globale variabelen vervangt, zoals niet-constante variabelen met class-scope. Dit is geen nieuw of radicaal standpunt: globale variabelen worden beschouwd als een bron van onvoorziene indirecte koppelingen, en ze bemoeilijken dus de documentatie, debugging en inzetbaarheid van componenten. Geen globale variabelen dus, maar wat dan met interne variabelen? Het moet toch mogelijk zijn om bepaalde gegevens bij te houden, al was het nog maar het opschrift van een simpele knop? Szyperski benadrukt dat het component niet mag verward worden met het object, en dat alle "state" in objecten moet worden bijgehouden. Een database component, bijvoorbeeld, mag niet verward worden met de eigenlijke gegevens, opgeslagen in een database met een zekere naam. Een filesystem component bevat zelf geen enkele informatie over een

7 toestand. In plaats daarvan voorziet het bewerkingen op objecten: de files. In theorie is het dus perfect mogelijk om het component filesysteem te vervangen in een run-time systeem. En hoewel een "delete" op een file heel anders kan geïmplementeerd in het nieuwe systeem, is de semantiek volledig dezelfde gebleven, en ondervinden de andere componenten in principe geen hinder van de hot swap. Alles komt dus neer op een tamelijk subtiel verschil in definitie van de term "component". Voor Szyperski staat een component gelijk aan een pakket van diensten. Vandaar ook zijn opmerking dat het, binnen een enkel software systeem, geen zin heeft om meer dan een component van hetzelfde type te installeren. Mijn eerste reactie daarop was dat de gemiddelde applicatie waarschijnlijk meer dan een knop zou gebruiken. Binnen Szyperski's filosofie zou een enkele knop eerder een object zijn, als onderdeel van het component "GUI". Dit staat haaks op bijvoorbeeld de JavaBeans definitie van een component, maar het leunt dichter aan tegen het COM model. 1.2 Bertrand Meyer In een reeks columns in dialoog met Szyperski [SDM], en vooral in "What to compose" van maart 2000 beschrijft Meyer wat volgens hem de kenmerken zijn van componenten. Veel van deze ideeën zijn al terug te vinden in zijn boek over object-oriented methoden [OOSC], maar het interessante aan de reeks columns is dat ze hier specifiek gebruikt worden om componenten te definiëren, en bovendien zijn ze geformuleerd in antwoord op Szyperski's definitie. "May be used by other software elements (clients)." De voornaamste bestaansreden voor componenten is gebruikt te worden door andere componenten. Samenstelling van componenten levert een totaal-systeem op dat een of meer taken kan uitvoeren, al of niet in interactie met de gebruiker. De vereiste dat componenten bruikbaar moeten zijn door andere stukken software, in plaats van de eindgebruiker legt bepaalde vereisten op in verband met de documentatie, de interface, en andere. Deze vereisten worden in de andere punten opgesomd. "May be used by clients without the intervention of the component's developers." Hergebruik is een van de belangrijkste beloften van component-georienteerd programmeren. Maar als de programmeur van het oorspronkelijke component aanwezig moet zijn om alles in goede banen te laten verlopen (bijvoorbeeld enkele aanpassingen van het component naar wens van de nieuwe klant), dan is natuurlijk alle voordeel verdwenen. Het idee achter componenten is dat een programmeur, eens alle functionele vereisten vastliggen, in een virtueel warenhuis langs de rekken zou moeten kunnen wandelen en de componenten selecteren die hem van pas kunnen komen. Daarna smeedt hij deze

8 tezamen met eigen code, en eventueel voegt hij nog enkele componenten van eigen makelei toe. Normaalgesproken kent de programmeur die de componenten in het warenhuis is gaan kopen de ontwikkelaar van de componenten dus niet, en toch moeten de componenten kunnen aangepast worden aan deze specifieke nieuwe situatie. Deze twee waren volgens Meyer de belangrijkste kenmerken voor componenten: hergebruik door andere software constructies, en hergebruik in een situatie waar de oorspronkelijke programmeur niet noodzakelijk bekend (of bereikbaar) is. Om deze twee mogelijk te maken, komen weer een aantal vereisten op de voorgrond, die Meyer in de volgende vijf puntjes heeft gegoten. "Includes a specification of all dependencies (hardware and software platform, versions, other components)." Om een component succesvol in te bouwen in een systeem, moet je weten wat dit component nodig heeft om te kunnen werken. Een component kan een bepaald stuk hardware nodig hebben, of het kan misschien alleen draaien onder een bepaald operating system. Maar het kan ook zeer goed zijn dat een component bepaalde andere componenten nodig heeft om te werken. Meestal wordt gezegd dat een component bepaalde diensten ("services") nodig heeft. Zo'n services moeten zeer nauwkeurig omschreven worden, zodat een development tool op een algoritmische manier kan bepalen of een bepaald component succesvol zal draaien binnen het ontworpen systeem. Als component A bijvoorbeeld een component nodig heeft dat de vuile was doet, dan moet JBuilder zeker weten dat component A de vuile was aan component B kan geven, en dat component B het gewassen en gestreken goed terug aan A zal bezorgen. De eis dat alle benodigde diensten nauwkeurig worden beschreven, heeft een logische tegenhanger: "Includes a precise specification of the functionalities it offers." Als JBuilder zeker wil weten dat alle vuile was van component A netjes zal behandeld worden, dan moet JBuilder erop kunnen vertrouwen dat component B alles zal doen. Gevolg: de diensten die component B aanbiedt, moeten nauwkeurig beschreven worden, zodat ze kunnen vergeleken worden met de diensten die component A vereist. Alleen als zowel de benodigde als geleverde functionaliteit formeel wordt beschreven, kunnen componenten gecombineerd worden volgens een bepaalde hiërarchie (een boom of een netwerk) van "A gebruikt B gebruikt C". Als de specificaties machinaal kunnen behandeld worden, kan een tool nagaan welke diensten nog ontbreken, en eventueel zelfstandig op zoek gaan naar een component dat deze dienst aanbiedt in ons virtueel warenhuis. "Is usable on the sole basis of that specification."

9 Als tools moeten zorgen voor compositie van componenten, dan staat of valt hun werking met de correctheid van de specificaties. Als component B van daarjuist plechtig belooft de vuile was te zullen doen, maar in plaats daarvan alle kledingstukken groen verft, dan zal het samengestelde systeem in de problemen komen. Tools moeten erop kunnen vertrouwen dat de formele specificatie ook werkelijk de semantiek van het component weergeeft. Het is onmogelijk voor een tool om eigenhandig het gedrag van een component te observeren en daaruit algemene conclusies te trekken over het toepassingsgebied van het component. Hoe kan de JBuilder zeker weten dat de kleren NOOIT kanariegeel zullen terugkomen? De dualiteit tussen specificatie en implementatie is een veelbesproken onderwerp, en ook Betrand Meyer besteedt hier de nodige aandacht aan [SDM][OOSC]. Specificaties, of interfaces zijn belangrijk om twee redenen: herbruikbaarheid ("reusability"), en vervangbaarheid ("substitutability"). Het idee van hergebruik is dat reeds software wordt ingeschakeld, zonder dat hiervoor noodzakelijk alle code opnieuw doorlopen wordt zodat een tijdsbesparing wordt gerealiseerd. Om het code-browsen te vermijden, is een specificatie nodig. Dit kan gaan van een informeel stuk tekst ("dit component kan uw was doen"), tot specifieke codes die door tools kunnen gelezen en geïnterpreteerd worden. Vervangbaarheid is het omgekeerde van hergebruik: in een bestaand systeem wordt een component verwijderd, en in plaats daarvan wordt een ander component geïnstalleerd met (op zijn minst) dezelfde interface ("wast witter dan wit!"). Dit kan alleen als alle andere componenten enkel kijken naar de interface, en niet naar de implementatie. Software engineering is vrij uniek ten opzichte van de andere ingenieursdisciplines, omdat het onderscheid tussen ontwerp en implementatie veel vager is dan in andere takken. Om het in de woorden van Bertrand Meyer te zeggen: "You can fall from the bridge, but not from the map, and you won't get an electric shock from the circuit diagram" [SDM]. De vereiste dat een component bruikbaar is enkel op basis van de specificatie lijkt dus triviaal voor andere ingenieursdisciplines, maar is dat niet altijd voor software. Heel dikwijls is het verleidelijk om documentatie te verwaarlozen uit tijdsgebrek of nonchalance, en even dikwijls is het ook verleidelijk (of zelfs noodzakelijk) om de werking van routines te controleren door de code na te gaan. Bij component-georienteerd programmeren is black box reuse dus niet alleen aangemoedigd, het is ook verplicht. En daarom is Bertrand Meyer zo blij dat componenten typisch gezien in binaire vorm worden verspreid: het is veel moeilijker om de exacte werking van een binair component te achterhalen [SDM]. Op die manier wordt "information hiding" (of "data encapsulation") afgedwongen op een manier die veel strikter is dan de meeste compilers kunnen garanderen. Omdat de source niet verkrijgbaar is, is het onmogelijk te code te inspecteren en kan dus enkel vertrouwd worden op de specificatie. En zelfs als de code toch beschikbaar is, vanuit de open-source filosofie, is het niet zo vanzelfsprekend om "even vlug" iets aan te passen in het component, omdat dat hier nu juist beter uitkomt. Szyperski werpt hiertegen op dat het onderscheid tussen binaire en leesbare vorm niet altijd even strikt is (denk maar aan scripts), en dat "data encapsulation" meestal niet de voornaamste reden is voor de binaire vorm van componenten, maar toch denk ik persoonlijk dat Meyer hier een goed argument heeft. Sterker nog: uit commerciële

10 overwegingen zou "information hiding" toch wel eens de belangrijkste drijfveer kunnen zijn voor de binaire vorm. "Is composable with other components." Bent u verrast? Het woord zelf suggereert dat componenten deel zijn van een groter geheel. Toch is de vereiste niet zo vanzelfsprekend als ze eerst lijkt. Zoals de voorgaande kenmerken duidelijk maken, komt er heel wat bij kijken om zinvolle combinaties van componenten mogelijk te maken. Meyer vernoemt het zelf pas in een andere column [SDM], maar hier komt ook het vraagstuk van de standaards bij kijken. "Wiring standards" worden ze genoemd, en ze zijn nodig om verschillende componenten gegevens te laten uitwisselen. Zowel Meyer als Szyperski zijn het erover eens [SZYP][SDM] dat teveel standaards het leven nodeloos ingewikkeld zouden maken, maar dat het langs de andere kant niet wenselijk is om een enkele standaard te hebben. Er zijn enkele gevaren verbonden aan pluggen die passen in apparaten die daarvoor niet bedoeld zijn, zoals Meyer duidelijk maakt in een klaagzang over zijn batterijlader die in rook opging [SDM]. Er is nog een ander aspect aan verbonden: Szyperski beschrijft hoe veel objectgeorienteerde frameworks impliciet aannemen dat ze het enige systeem zijn, en dus moeilijk gecombineerd kunnen worden met andere frameworks. Dit maakt duidelijk dat programmeren met hergebruik in het achterhoofd niet noodzakelijk hetzelfde is als programmeren met combineerbaarheid in het achterhoofd. "Can be integrated into a system quickly and smoothly." Hoe makkelijker, hoe liever. Aangezien de vorige zes kenmerken allemaal de eenvoudige integratie van componenten tot doel hebben, verdenk ik Meyer er hier van een beetje breedsprakig geworden te zijn. In de column in kwestie [SDM] stond niet veel extra uitleg bij dit punt, maar ik vermoed dat Meyer hier duidt op het feit dat een component typisch gezien ook code bevat die specifiek is voorzien om het integratie-proces gemakkelijker te maken. Ik denk hierbij aan run-time checks op de parameters, op de interne consistentie, op routines om hotswapping mogelijk te maken, etc. In "klassieke" hergebruikte code vind je zo'n run-time checks niet vaak terug, omdat samenstelling meestal gebeurt op compile-time, en de compiler dus de meeste checks uitvoert. 1.3 Bruce Powel Douglass Bruce Powel Douglass was een van de auteurs die gevangen zat in het spervuur van columns tussen Bertrand Meyer en Clemens Szyperski [SDM]. Hij heeft zelf enkele

11 columns geschreven, waarvan sommige een antwoord op de vragen die Meyer en Szyperski elkaar en zichzelf stelden. Douglass' definitie van componenten samenvatten is makkelijk, want hij doet het voor ons [SDM]: "A component is really a large-scale object used in an idiomatic way." Hij gaat verder met verklaren dat een component kan bestaan uit zowat elke grootteorde. Typisch gezien is een component kleiner dan een subsysteem van de architectuur, en typisch omvat het een of meerdere objecten. Doordat Douglass een component identificeert met een enkele interface, suggereert hij nochtans dat een component slechts bestaat uit een object, en ook elders gaat hij van deze veronderstelling uit. Zo'n object moet dan wel aan bepaalde vereisten voldoen om een component te kunnen zijn. Het voornaamste doel van deze eisen is de vervangbaarheid van een component binnen een bestaand systeem te vergemakkelijken. Merk op dat hij hiermee voorbijgaat aan een tweede aspect, namelijk de samenstelling van componenten tot een nieuw systeem. Douglass beperkt zich tot twee brede eisen: ten eerste moeten interface en implementatie duidelijk gescheiden zijn, en ten tweede moet het component grondig gedocumenteerd zijn. Documentatie moet zowel de interface als de pre en postcondities en varianten omvatten, het moet de aanvaardbare sequenties van functie aanroepen (het protocol) vastleggen, en ook het "gedrag". Protocol en gedrag kunnen onder andere vastgelegd worden door een "state diagram". In scherpe tegenstelling tot Szyperski, laat Douglass expliciet toe dat components ook "state" bevatten. Hun gedrag is dus niet alleen afhankelijk van de huidige parameters, maar ook van alle vorige function calls en hun parameters. Het voorbeeld dat hij aanhaalt omvat enkele componenten van hetzelfde type, namelijk twee verkeerslichten. Ook dit is in strijd met wat Szyperski eerder aanhaalde als definitie van een component. Douglass is zich hiervan bewust, maar gaat jammer genoeg niet dieper in op de reden hiervoor. Een polemiek over "statefulness" van componenten, hoewel nogal detaillistisch, had nochtans wel licht kunnen werpen op de verschillende impliciete stellingnames van de auteurs. Het ziet ernaar uit dat Douglass -samen met Meyer- componenten eerder ziet als geïnstantieerde objecten met een identiteit, dichter bij de definitie van CORBA componenten dan COM componenten. 1.4 Siemens Gang of Five Genoemde desperado's zijn eerder berucht om hun werk op het gebied van patterns, maar in hun boek [SGOF] op pagina 385 geven ze ook een expliciete definitie van een component: A component is an encapsulated part of a software system. A component has an

12 interface. Components serve as the building blocks for the structure of a system. At a programming-language level, components may be represented as modules, classes, objects or a set of related functions. Zoals ze zelf verder ook aangeven, hebben ze het woord component heel ruim opgevat. De definitie gaat voorbij aan aspecten zoals het doel van component-georienteerde ontwikkeling, het geeft niet aan waarom een component geïnkapsuleerd is, en het legt niet meteen nadruk op het belang van scheiding tussen interface en implementatie. Aspecten zoals hergebruik, combineerbaarheid, semantiek en dergelijke worden volledig terzijde gelaten. Hoewel de definitie niet veel zegt over "good practice" in verband met componenten, komen toch veel aspecten van hergebruik, inkapsulatie, vervangbaarheid en evolueerbaarheid en dergelijke aan bod in het book. Niet onlogisch, aangezien patterns een poging zijn om "good practice" op een heldere manier op te slaan en door te geven. Veel van de patterns die betrekking hebben op objecten kunnen integraal worden toegepast op componenten. Het "observer" patroon, bijvoorbeeld, wordt intensief gebruikt bij JavaBeans en in de Beanbox, waar event-handling altijd gebeurt via het toevoegen van "listeners". Hierover later nog meer. 1.5 Andere Veel boeken die software ontwikkelingstechnieken bespreken, of die verwijzen naar hergebruik in het algemeen, zullen vroeg of laat de term "component" gebruiken. Het woord heeft dan niet noodzakelijk alle extra betekenissen die het in andere werken of deze thesis krijgt. "Component" is immers geen nieuw uitgevonden term, en dikwijls wordt het gebruikt in de klassieke betekenis van onderdeel van een compositie. Ivar Jacobson, Martin Griss en Patrik Jonsson vermelden in hun boek [IMP] op pagina 85 expliciet dat ze het woord gebruiken in de breedst mogelijke zin: A component is a type, class or any other workproduct that has been specifically engineered to be reusable. Aangezien hun boek specifiek over hergebruik gaat, ligt de klemtoon bij componenten meer bij hergebruik dan bij de andere aspecten, zoals vervangbaarheid, run-time combineerbaarheid en dergelijke. Ook Carlo Ghezzi, Mehdi Jazayeri en Dino Mandrioli staan nauwelijks stil bij het woord "component". Het boek beschouwt modularisatie technieken in het algemeen als een manier om een groot probleem onder te verdelen in verschillende kleinere problemen, die elk eenvoudiger op te lossen zijn en/of recursief onder te verdelen. Een goede module (of

13 component) vertoont natuurlijk wel eigenschappen zoals "data encapsulation", functionele cohesie, losse "coupling" met andere modules, enzovoort [FUND]. Dit toont aan dat veel aspecten van component-georienteerd programmeren weinig revolutionair zijn, maar eerder goede algemene principes die al zeer lang gekend zijn. 1.6 Kenmerken van componenten Gebaseerd op de auteurs die hiervoor besproken zijn, en op enkele huidige standaards voor component-systemen, ben ik tot een eigen definitie gekomen van componenten: Een component is een softwarematige eenheid, dikwijls binair, waarbij speciale inspanning is geleverd op vlak van interfaces, documentatie en code met als voornaamste doel samenstelbaarheid, herbruikbaarheid en vervangbaarheid. Zoals elke zichzelf respecterende definitie vergt ze enige toelichting. Een component wordt gedefinieerd als een eenheid. Dit betekent dat, zelfs al is ze samengesteld, naar buiten toe fungeert het als een enkel... component. Er is geen onderverdeling mogelijk, het is niet mogelijk een component deels te herbruiken of enkele stukken aan te passen aan nieuwe behoeften. Dat componenten dikwijls binair worden verspreid is om deze eenheid nog strikter op te leggen. De interfaces zijn een formele beschrijving van de aangeboden en de vereiste functionaliteit. Het is een informatiestroom van het ene software-tool naar het andere. Componenten zoeken en samenstellen moet op basis van de interface kunnen gebeuren, en het moet grotendeels automatisch kunnen gebeuren. Een sterke scheiding tussen interface en implementatie komt ten goede aan zowel samenstelbaarheid, herbruikbaarheid als vervangbaarheid. Documentatie beschrijft het component op een minder formeel niveau. Het is informatie van de component-ontwikkelaar naar de component-gebruiker, die typisch ook een programmeur is. Documentatie dient om samenstelbaarheid en herbruikbaarheid te vergroten. Inspanningen op vlak van de code kunnen beschouwd worden als een informatiestroom van het component naar de omringende componenten. Ze beinvloeden rechtstreeks de samenstelbaarheid, herbruikbaarheid en vervangbaarheid van het component. Extra code om de binnenkomende parameters te controleren vergroot bijvoorbeeld de samenstelbaarheid. Extra code die rekening houdt met zoveel mogelijk verschillende situaties vergroot de herbruikbaarheid. Extra abstractie-lagen en strikte scheiding van specificatie en implementatie vergroten de vervangbaarheid. Samenstelbaarheid is een essentieel kenmerk van componenten: het laat toe de functionaliteit van verschillende componenten te combineren om uiteindelijk een software

14 systeem te bekomen dat voldoet aan gestelde eisen. Een van de constructies om samenstelbaarheid te vergroten zijn de "wiring standards" zoals COM, CORBA en JavaBeans. Een zeer sterke vorm van samenstelbaarheid is samenstelbaarheid op runtime. Voor Szyperski is dit zelfs een noodzakelijke voorwaarde om van een component te spreken. Herbruikbaarheid is de droom van elke "software engineer": door bestaande componenten in te voegen, is het mogelijk een software systeem te realiseren met veel minder tijd en middelen dan nodig zouden zijn om alles van nul te ontwikkelen. Als de herbruikbaarheid van een component optimaal is, moet de gebruiker van een component niet noodzakelijkerwijs in contact staan met de oorspronkelijke ontwikkelaar van het component. Meyer's vereiste dat een component hergebruikt moet worden zonder tussenkomst van de oorspronkelijke ontwikkelaar zit dus eerder impliciet vervat in de definitie. Vervangbaarheid komt ten goede aan wat Szyperski "evolvability" noemt: als een component kan vervangen worden door een nieuw component dat dezelfde interface realiseert, kan het systeem stap voor stap evolueren zonder dat er grote, algemene upgrades moeten gebeuren die tijdelijk het volledige systeem lamleggen en die een bedrijf dus extra tijd en geld kosten. Indien het systeem erop voorzien is, kan een bepaald component zelfs bij run-time vervangen worden, zonder enig tijdverlies. Een ander voordeel van vervangbaarheid is de mogelijkheid tot eenvoudige invoeging van een component waarvan een software fout is verbeterd, of waarvan de niet-functionele eigenschappen (zoals systeemvereisten of snelheid) zijn verbeterd. Enkele algemene principes die de vervangbaarheid ten goede komen zijn een sterke scheiding van specificatie en implementatie, en ook een lage "coupling" tussen de verschillende componenten. Nog een laatste opmerking: deze definitie gaat de discussie over "statefulness" uit de weg, om twee redenen. Ten eerste is het vermijden van "statefulness" (onder de vorm van globale variabelen, enz) volgens mij geen noodzakelijke voorwaarde om een component te maken. Het is natuurlijk wel een heel goed idee om dergelijke addertjes te vermijden, en dus valt het vermijden van "statefulness" onder de noemer "speciale inspanning met als doel " enzovoort. Ten tweede geloof ik dat Szyperski's definitie van een component niet wezenlijk van andere definities. Een stuk software dat component-georienteerd is volgens de definitie van Meyer, zal ook component-georienteerd zijn volgens Szyperski. Alleen zal Meyer een aantal objecten aanwijzen en zeggen: "dit zijn verschillende componenten die hetzelfde gedrag vertonen, en dus tot dezelfde klasse kunnen gerekend worden", terwijl Szyperski dezelfde objecten zal aanwijzen en zeggen: "dit zijn verschillende manifestaties van hetzelfde component".

15 2 Distinctie Bij elke nieuwe methodiek, hype of nieuw paradigma, is het belangrijk om zich af te vragen of het niet gaat om oude wijn in nieuwe flessen. In dit hoofdstuk wordt componentgeorienteerd programmeren vergeleken met enkele andere paradigma's. 2.1 Object-Oriented programming Wat bieden componenten meer dan objecten? De twee worden wel eens door elkaar gebruikt, en om alles nog makkelijker te maken is het onderscheid tussen klassen en objecten ook niet altijd even strikt. Een anekdote als voorbeeld van verwarring tussen objecten en klassen. In de tweede kandidatuur moesten we ("wij", dat waren toen "the RUCA Lions". Bescheidenheid is voor kwezels!) een object-georienteerd programma ontwerpen dat het virtueel geheugen in een computer nabootste. Na veel vijven en zessen hadden we een prachtig UML schema: "de processor" genereert een logisch adres, en geeft het door aan de MMU. De MMU vertaalt dit naar een virtueel adres. Dit adres kan ofwel gecached zijn, ofwel verwijzen naar een fysiek adres in het RAM geheugen, ofwel naar een adres of de harddisk, zodat het moet worden ingeswapped. De MMU sprak dus cache, RAM of disk aan, en gaf (eventueel na een swap) de waarde van het gevraagde adres terug aan de CPU. In ons software model zaten dus enkele vereenvoudigingen (zoals MMU die zelf de harddisk aansprak), maar al bij al vonden we dat we een "clean" model hadden weten op te bouwen. Nu was een van de opdrachten voor het project dat we de gebruikte strategieën moesten kunnen vervangen. Het moest dus mogelijk zijn een nieuwe MMU of een nieuwe cache te installeren, elk met specifieke vervangingsstrategieën. Zowel de cache als het RAM geheugen moesten van grootte kunnen veranderen, om de weerslag te kunnen meten op het swap gedrag van onze virtuele virtuele (sic) machine. De problemen begonnen pas bij het implementeren. De MMU bijvoorbeeld was een object dat bijna alle ander objecten moest kunnen aanspreken, en omgekeerd. Maar tegelijk moesten vele objecten ook kunnen vervangen worden terwijl het programma liep. In onze prachtige schema's liepen er simpelweg een aantal pijlen van MMU naar CPU, van MMU naar cache, van MMU naar RAM. In praktijk bleken er verschillende kandidaat-mmu's te zijn, en verschillende kandidaat-caches, enzoverder. We hebben alles dan opgelost door middel van stapels en stapels pointers, en ontwierpen we een heel stel ingewikkelde procedures om ervoor te zorgen dat als bijvoorbeeld de cache werd vervangen, dat dan alle pointers naar de huidige cache ook vervangen werden.

16 Wat was er gebeurd? Het antwoord op deze vraag kwam pas bij me op terwijl ik deze thesis aan het voorbereiden was: we hadden het prototype verward met de eigelijke objecten. In ons model sprak het prototype van de MMU het prototype van het RAM geheugen aan. We stonden niet stil bij de vraag hoe de MMU het RAM geheugen zou vinden. Dat leek ons even vanzelfsprekend als de kwestie hoe het MMU de klassedefinitie van het RAM geheugen zou weten te vinden. We hadden het onbewuste idee dat als we de headerfile van de RAM-klasse toevoegden aan de code van de MMU, dan liet de compiler ons toe om het RAM aan te spreken. Maar weten dat een bepaalde klasse bestaat is nog niet genoeg om ook effectief objecten van die klasse terug te vinden. Onze ontwerpen hielden dus geen rekening met het onderscheid tussen klasse en object. Bij componenten is het onderscheid tussen klasse en object, tussen specificatie en implementatie, zo mogelijk nog belangrijker. Ik zou willen beginnen met te zoeken naar een goede definitie van wat objecten juist zijn, en van daaruit te vertrekken om duidelijk te maken dat componenten een meerwaarde bieden Object-Oriented Programming: a Unified Foundation [OOPUF] Dit boek biedt een formele notatie om eigenschappen van object-georienteerde talen te beschrijven. Het benadert object-orientatie vanuit een sterk taal-theoretische hoek, en minder vanuit de "software engineering" hoek. De potentiële voordelen van componenten liggen echter niet in het taal-theoretische. Component-georienteerd programmeren wordt niet geassocieerd met een volledig nieuwe programmeertaal, maar vertrekt vanuit bestaande talen zoals C++, Java, VB, Eiffel, en andere. Maar het boek kan misschien wel dienen om een goede definitie van object-orientatie te geven. Op pagina 38 staat: Objects are programming items grouped in classes and possessing an internal state that may be accessed and modified by sending messages to the object. Iets verder, op pagina 40 staat: An object is a programming unit that associates data with the operations that can use or affect these data. Een object is dus, net als een component, een eenheid. Dit suggereert dat objecten geschikte constructies kunnen zijn om componenten van te bouwen. Het definieert een aantal operaties. Dit is gelijkaardig met de interfaces van componenten, maar in deze definitie is met opzet in het ongewisse gelaten hoe de definitie van operaties juist gebeurt. Merk ook op dat de eerste definitie expliciet gewag maakt van een "internal state", en dus tot op zekere hoogte onverenigbaar is met de definitie van componenten die Szyperski geeft.

17 Giuseppe Castagna beschouwt "late binding" als de belangrijkste eigenschap van objectorientatie: als een member-functie van een object wordt opgeroepen, is het op compiletime niet meer noodzakelijk bepaald welke code precies zal worden uitgevoerd. Als "vorm" een interface is die de methode "draw()" bevat, kunnen het object "vierkant" en het object "cirkel" (beide subtypes van "vorm") deze methode een heel andere invulling geven. Als ons tekenprogramma dan een "vorm" moet tekenen, roept het simpelweg de methode "draw" op, zonder te moeten nagaan of de vorm in kwestie nu een vierkant, cirkel, of iets geheel nieuw is. Terzijde: Castagna brengt late binding terug tot een vorm van function overloading, waarbij hij aantoont dat typische object-georienteerde talen een zekere vorm van function overloading negeren, omdat ze uitgaan van minimale informatie bij het compileren. Dat is eenvoudig aan te tonen met twee functies die dezelfde naam hebben, maar waarbij de een een argument van het basistype aanvaardt, terwijl de andere een argument van het subtype aanvaardt. De voorbeeld-code toont aan dat onder bepaalde omstandigheden de functie wordt aangeroepen die het basistype behandelt, terwijl toch een subtype als argument werd gegeven. Om terug te komen op de relatie tussen objecten en componenten: de "late binding" bevordert vervangbaarheid doordat een subtype kan gebruikt worden waar een basis type werd verwacht, en het bevordert samenstelbaarheid doordat nieuwe subtypes kunnen gebruikt worden door code die geschreven kan zijn nog voor het subtype bekend was. Het mag duidelijk zijn dat "late binding" een belangrijk hulpmiddel is bij zowel object-orientatie als bij componenten. Szyperski introduceert nog een hulpmiddel voor componenten: "very late binding" [SZYP] A Theory of Objects [THEO] Het boek opent met een definitie van objecten op pagina 8: The Object-Oriented approach to programming is based on an intuitive correspondence between a software simulation of a physical system and the physical system itself. An analogy is drawn between building an algorithmic model of a physical system from software components and building a mechanical model of a physical system from concrete objects. By analogy, the software components are themselves called objects. Merk op dat het woord "components" hier wordt gebruikt in de meest algemene betekenis: onderdeel van een samenstelling. Voor de rest benadrukt de definitie een overeenkomst tussen de objecten binnen de software, en de objecten in de wereld die door de software gemodelleerd wordt. Hier schuilt zowel de sterkte als het gevaar bij object-georienteerde analyse: object is zowat het meest vage woord dat er bestaat in het vocabularium van een

18 taal, en het kan werkelijk op alles slaan. Het boek ontleedt de grote en vage groep van objecten in drie delen, die elk geassocieerd worden met een fase binnen een objectgeorienteerd project. In de analyse-fase zijn objecten concrete dingen die gemodelleerd zullen worden. Als bijvoorbeeld een softwarepakket wordt ontworpen om een zonnestelsel uit te beelden zullen de objecten planeten zijn. In de designfase komt er een soort objecten bij: ze zijn geconcretiseerde abstracties, nodig om het model te beschrijven. Planeten, bijvoorbeeld, hebben elk hun eigen omloopbaan. Dit zijn geen fysieke entiteiten meer, maar wel degelijk "dingen" (let op de vage term) om het model te laten werken. Uiteindelijk resulteert dit alles in software-matige implementaties, in code die onderverdeeld is in objecten. Sommige daarvan zijn de implementatie van de fysieke objecten (planeten), andere van de abstracties (omloopbanen), en nog andere zijn alleen gecreëerd om technische implementatie-redenen (lijsten, abstracte datatypes,...) Dit alleen maar om mijn punt te onderstrepen dat component-georienteerd programmeren in hetzelfde bedje ziek is. Het woord "component" is net zo vaag als "object", en net zo vatbaar voor misverstanden. Ook componenten zullen gebaseerd zijn op een intuïtieve overeenkomst tussen een software-model en de fysieke wereld waar de software betrekking op heeft. Zo zullen er componenten zijn die betrekking hebben op fysieke entiteiten. In het project dat deze thesis vergezelt zitten bijvoorbeeld componenten die personen voorstellen, of kaarten uit het spel. Daarnaast bestaan er componenten die bepaalde abstracties voorstellen. In mijn project zitten componenten die "schade" voorstellen, of een component dat het spelverloop voorstelt. Dat component vervangen zou betekenen dat andere spelregels gelden. En tenslotte bestaan er componenten die gecreëerd zijn enkel omdat ze de creatie van software vergemakkelijken. Een database component bijvoorbeeld stelt niks uit de fysieke wereld voor, maar maakt het wel een stuk makkelijker om bepaalde gegevens op te slaan en terug te vinden. In deze zin vertoont component-georienteerd ontwerpen dus veel overeenkomsten met object-georienteerd ontwerpen. Ik denk dat het voornaamste verschil er een van schaal is: in een component-georienteerd ontwerp zal een component typisch gezien groter zijn en/of een belangrijker deel uit de werkelijkheid modelleren dan een object. Maar dit is geen wetmatigheid, en in object-georienteerde systemen kunnen zeker objecten voorkomen die groter zijn dan een flink uit te kluiten gewassen component "Het beste boek Java 2.0" Het ontbreekt dit boek nochtans niet aan ambitie, maar uiteindelijk is de bedoeling van het boek het aanleren van een enkele programmeertaal: Java. Omdat Java een objectgeorienteerde taal is, waagt het boek zich ook aan een definitie van object-orientatie. Ik heb dit boek genomen als voorbeeld voor meer populaire literatuur, die programmeren niet zozeer vanuit de academisch-theoretische hoek benadert, maar vanuit een semiprofessionele hoek. Op pagina 241 staat:

19 In plaats van programma's op een top-down lineaire manier aan te pakken zoals traditionele programmeertalen zoals Pascal of C, probeert OOP een probleem in onderdelen te splitsen. De oplossing concentreert zich op deze onafhankelijke objecten en hun relatie met andere objecten. Het eerste dat me opviel was een sterke identificatie van programmeertaal met het programmeerparadigma. Dit is niet altijd onterecht: vele talen werden ontworpen om nieuwe inzichten in te verwerken, en lenen zich dus beter tot dat ene paradigma dan tot andere. Zo werd Pascal ontworpen om procedureel programmeren te vergemakkelijken. Modula-2 zag het levenslicht om nieuwe vereisten in verband met apart compileren in te vullen. Oberon om object-georienteerde concepten in te verwerken, en Eiffel kwam er om ideeen over object-orientatie en hergebruik in te verwerken. Toch is het perfect mogelijk om in Oberon of Eiffel op een procedurele manier te werken, en object-georienteerde constructies te negeren. Omgekeerd is het ook mogelijk om zelfs in assembler op een object-georienteerde manier te werk te gaan. Alleen zijn er geen speciale constructies voorhanden om alles makkelijker en minder foutgevoelig te laten verlopen. Toch is de link tussen taal en paradigma niet vergezocht. Misschien is het wel een goed idee om een taal te ontwerpen die specifiek bedoeld is om componenten in te programmeren? Hier zou ik graag op terugkomen in het verlanglijstje. De definitie stelt ook dat er een contrast is tussen object-georienteerde analyse, en de "top-down lineaire manier". Hoewel het boek daarmee doelt te suggereren dat de objectgeorienteerde manier makkelijker of natuurlijker is, duidt het wel op een mogelijk probleem bij object-georienteerd design: de niet-lineariteit van de resulterende constructie. Szyperski behandelt de mogelijke gevaren in meer detail Clemens Szyperski [SZYP] Szyperski's definitie van objecten is zeer summier: "encapsulation of state and behaviour, polymorphism, and inheritance" [SZYP]. Tegelijk zijn dit ook allemaal eigenschappen van componenten. Verder op pagina 10 wordt ook weer duidelijk dat Szyperski en andere auteurs lichtjes verschillende visies hebben op componenten, en dus hun relatie tot objecten. Szyperski stelt vast (hoewel hij geen bronnen vernoemt) dat individuele objecten bijna nooit worden verkocht of ingezet. Hij concludeert daaruit dan een component dus een meer statische eenheid is: een klasse, of een groep klassen (bv. in een module). Vandaar ook zijn stelling dat een component als geheel nooit een instantie is, in tegenstelling met bijvoorbeeld de visie van Meyer of met het idee achter Javabeans. Maar wat maakt een component dan meer dan een -of meer- klassen? Ten eerste omvat de definitie van objecten geen eisen omtrent samenstelbaarheid, en ze gaat ook voorbij aan commerciële eisen. Er is nooit een levende markt gekomen voor objecten (of klassen)

20 gekomen, op enkele succesvolle uitzonderingen na, en dat valt te verklaren door de catch 22 rond objecten en ook componenten: de extra inspanning die het kost om een wijd herbruikbaar component te maken in plaats van een specifieke oplossing, is alleen gerechtvaardigd als het wordt terugverdiend op de markt [SZYP]. Zo'n markt moet dus al bestaan voor ze op gang kan komen. Szyperski noemt ook nog een aantal andere oorzaken waardoor object-georienteerde technologie er mogelijks niet in is geslaagd om een bloeiende markt in objecten te starten. Een typisch object (en naar mijn mening ook een klasse; al lijkt Szyperski hier het onderscheid niet te maken) heeft geen duidelijke bedoeling voor de eindgebruiker. Het is meer een gebruiksvoorwerp van de doorgewinterde programmeur. Zelfs in het beste geval is hergebruik van objecten (en klassen) dus voorbehouden voor een relatief kleine doelgroep. Meestal zijn ze zelfs helemaal niet bedoeld voor hergebruik door een derde partij, maar hoogstens door de oorspronkelijke programmeur. Om woorden te gebruiken uit mijn eigen definitie voor componenten: meestal zijn te weinig inspanningen geleverd om samenstelbaarheid en uitbreidbaarheid te garanderen. Een andere eigenschap van object-georienteerd design is dat ze niet noodzakelijk lineair is. Terwijl een procedureel design vrij sterk gelaagd is (toepassing bovenop libraries bovenop systeemsoftware bovenop hardware), leent object-orientatie er zich toe om een veel minder gelaagd systeem op te bouwen met clusters of netwerken van objecten die elkaar kunnen aanspreken. Constructies als inheritance en overloading creëren extra verbindingen die gewoonlijk laag-overschrijdend zijn, en dus de lineariteit niet ten goede komen. Op pagina 48 en verder doet Szyperski uit de doeken welke gevaren er kunnen optreden als de top-down lineariteit wordt doorbroken. In functionele omgeving (zonder callbacks) kunnen functies alleen beroep doen op functies die in dezelfde of een lagere laag gesitueerd zijn. Deze functies kunnen op hun beurt dan weer functies oproepen uit dezelfde of onderliggende lagen. Met andere worden: controle wordt nooit aan een hogere laag teruggegeven voordat de lagere functies volledig uitgevoerd zijn en de onderliggende laag dus terug in een stabiele, consistente toestand is. De pre- en postcondities van een functie in de onderliggende laag laten geen ruimte voor glitches: voor de aanroep van de functie moet de preconditie gelden, als de functie terugkeert moet de postconditie gelden. De bovenliggende laag merkt niks van de uitvoering van de onderliggende functie, en kan dus ook geen inconsistente toestand opmerken. Vervolgens doet Szyperski uit de doeken hoe callbacks deze schijnbaar triviale vereiste kunnen doorbreken. Een callback functie is deel van een hoger-gelegen laag, maar ze wordt opgeroepen vanuit een lager deel uit de hiërarchie. Terwijl de onderliggende laag dus nog bezig is met de verwerking van een opdracht (de onderliggende functie is nog niet beeindigd), wordt de hogere laag terug actief. Op dat moment is het mogelijk dat de bovenliggende laag (de callback functie) een toestand waarneemt die niet consistent is. Dit is allemaal nogal abstract, en ik verwijs graag naar Szyperski's boek voor een meer gedetailleerd voorbeeld. Als we overgaan naar objecten, dan kan ik een voorbeeld geven dat geinspireerd is op wat Szyperski aanvoerde, maar specifiek toegepast op java. Voor