[vb.net] delegates

[Verwijderd]

hallo allemaal

ik heb in mijn boek van vb.net gelezen over delegates daar staan enkel voorbeelden hiervan in
omdat ik het concept niet snap ging ik naar volgende site
http://msdn.microsoft.com...temdelegateclasstopic.asp
maar hier staan ook weer enkel voorbeeldjes in weet er iemand waarvoor je nu delegates kan gebruiken.
Ook op de site van gotdotnet vind ik niets.

Weet er hier iemand een goede site met uitleg of kan hier iemand posten waarvoor hij delegates gebruikt many thanks
Tom

[whoami]

Een Delegate kan je een beetje vergelijken met een 'functie-pointer'.
Het is dus een variable waaraan je een method kan toewijzen.

Dit komt van pas als je bv. een class hebt, en die moet op een gegeven moment 'iets' doen. Delegates kunnen hier van pas komen als de class zelf niet weet wat ze precies moet doen, en kan het 'doorgeven' aan een andere class.

Bv, je hebt een class A.
Een object van class A gebruikt ook een class B object:

code:

public void MethodVanA()
{
    ClassB b = new ClassB();
    b.Work();
}

Stel nu dat de 'Work' method van B 'iets' moet doen als er een bepaalde voorwaarde voldaan is, bv, iets gaan updaten in class A.
Hiervoor kan je een delegate gebruiken.
_{hmmm, beetje krom uitgelegd}

Events maken bv gebruik van delegates.

Voorbeelden hoe je nog delegates kunt gebruiken:

klik

klik2

[ Voor 24% gewijzigd door whoami op 24-01-2005 14:40 ]

[Verwijderd]

dus als ik het goed begrijp is dit om een referentie dan te vermijden hier dan een referentie van klasse a ben ik juist ?

thx he

[whoami]

Delegates kunnen er idd voor zorgen dat je minder 'koppeling' hebt tussen classes.

[Verwijderd]

Verwijderd schreef op maandag 24 januari 2005 @ 14:33:
ik heb in mijn boek van vb.net gelezen over delegates daar staan enkel voorbeelden hiervan in
omdat ik het concept niet snap ging ik naar volgende site
http://msdn.microsoft.com...temdelegateclasstopic.asp

Wat ik niet snap is waarom je in hemelsnaam functies in classes met public-definitie kunt aanroepen zonder een instantie van die class aan te maken. Waarom worden de functies niet gedeclareerd als protected ofzo? Dit zie ik overigens in heel veel voorbeelden van Microsoft terug komen.

[Feyd-Rautha]

Door middel van Delegates kun je een method incapselen in een delegate-object. Het type van dat delegate-object specificeert de signature waaraan de ingecapselde method moet aan voldoen.

Je kan ook delegates-objecten combineren zodat je meerdere methods in een delegate-object kan incapsuleren.

Met behulp van delegates kun je dus methods als 'first-class' objecten gebruiken. Dat wil zeggen: methods als argumenten doorgeven of als return-value gebruiken. In OO talen zijn bijvoorbeeld objecten 'first-class'.

[ Voor 5% gewijzigd door Feyd-Rautha op 24-01-2005 16:46 ]

[whoami]

functies in classes die je kan aanroepen zonder een instance ervan te maken, zijn static methods.
Ik snap ook niet wat dit met 'protected' zou te maken hebben?

...of ik begrijp niet wat je wilt zeggen.

[whoami]

Feyd-Rautha schreef op maandag 24 januari 2005 @ 16:45:
Met behulp van delegates kun je dus methods als 'first-class' objecten gebruiken. Dat wil zeggen: methods als argumenten doorgeven of als return-value gebruiken. In OO talen zijn bijvoorbeeld objecten 'first-class'.

Moet ge ne keer tonen dat ge uw les 'OO software ontwerp' kent?

[curry684]

Delegates zijn eigenlijk een compleet foute uitbreiding van een OOP-taal omdat ze enkele basisbeginselen met contract-by-interface volstrekt overtreden. Stel dat je een class Button hebt die als er een click plaatvind iets moet doen. Volstrekt correct zou zijn als volgt:

C#:

public interface IButtonClickHandler
{
  void OnClick(Button origin);
}

public class Button
{
...
  private IButtonClickHandler     OnClick;   // met accessor property natuurlijk
}

Dit is de puristisch perfecte methode, echter hiermee kom je snel in de problemen: een gemiddelde GUI heeft al snel tientallen buttons, en doordat je een unieke functie maar 1 keer kunt implementeren per class zul je dus voor iedere button een aparte clickhandler class moeten maken. In principe correct, maar enorm k*twerk Delegates lossen dit op door het contract te abstraheren tot de signature van de functie ipv de naam, waardoor eeniedere functie die de correcte parameters accepteert een volwaardige kandidaat is om een callback of event af te handelen. Hiermee kun je dus alle tig clickhandlers in dezelfde class houden. Nadeel is dan wel weer dat het een zo flexibel mechanisme is dat je er snel ranzige trucs mee uit kunt gaan halen, zoals events onderbrengen in random externe classes waarmee je eigenlijk je hele model om zeep helpt. Tis een afweging

Delegates zijn een mooi principe hoor, Borland heeft het al sinds 1996 of zo in BCB zitten als 'closures' en het blijft een tekortkoming dat std-C++ ze bijvoorbeeld nog steeds niet ondersteunt zonder ranshacks, maar je kunt er ook teveel misbruik van maken

[Feyd-Rautha]

SmallTalk (+/- 1975) heeft het al zitten als 'blocks' (= closures)

[Verwijderd]

whoami schreef op maandag 24 januari 2005 @ 16:46:
functies in classes die je kan aanroepen zonder een instance ervan te maken, zijn static methods.
Ik snap ook niet wat dit met 'protected' zou te maken hebben?

...of ik begrijp niet wat je wilt zeggen.

Je kunt hiermee de constructor(s) en destructor omzeilen en dat lijkt mij normaal gesproken niet de bedoeling.

OP:
Je kunt een delegate zien als een functiedeclaratie waarvan de implementatie van de functie nog niet bekend is. At runtime zou je hiermee het gedrag van de applicatie kunnen beinvloeden.
Bijvoorbeeld afhankelijk van de input die je geeft aan de constructor van de klasse kun je het gedrag veranderen zonder ingewikkelde if-statements.

[whoami]

Verwijderd schreef op maandag 24 januari 2005 @ 17:04:
[...]

Je kunt hiermee de constructor(s) en destructor omzeilen en dat lijkt mij normaal gesproken niet de bedoeling.

Nee, want je maakt geen object aan, dus heb je geen instance - constructor nodig.
Je kan echter ook een 'static constructor' maken als dat nodig mocht zijn.
static methods == stateless, dus , je hebt geen state binnen de class. Een static method kan niet aan de statefull members van een class, dus waarom zou je die constructor dan uberhaupt nodig hebben?

[curry684]

Verwijderd schreef op maandag 24 januari 2005 @ 17:04:
[...]

Je kunt hiermee de constructor(s) en destructor omzeilen en dat lijkt mij normaal gesproken niet de bedoeling.

Static methods kunnen helemaal niet bij de content van een instance omdat ze per definitie niet aan een instance gebonden zijn, ergo static methods hebben helemaal niets van doen met constructors of destructors. Nogal wiedes dus ook dat ze constructors en destructors expliciet 'omzeilen'.

[.oisyn]

whoami schreef op maandag 24 januari 2005 @ 17:07:
static methods == stateless,

Dat is natuurlijk ook niet waar, een static kan prima bij andere statische variabelen, derhalve kunnen ze prima statefull zijn.

[whoami]

Mierenneuker.

Je hebt wel gelijk, maar ik noem dat nu ook niet echt 'statefull'.

_{moet je me hebben ofzo?}

[.oisyn]

whoami schreef op maandag 24 januari 2005 @ 17:40:
Je hebt wel gelijk, maar ik noem dat nu ook niet echt 'statefull'.

Mja hoe jij het noemt moet je natuurlijk zelf weten
Ik vind het alleen een beetje ver gaan om te stellen dat ze geen staat (kunnen) hebben, wat uiteraard best kan.

_{moet je me hebben ofzo?}

[Verwijderd]

offtopic:
een static getInstance() methode waarmee je een singleton tevoorschijn tovert is ernstig statefull hoor

voorbeeld van een zinvol (mwahh iig duidelijk en simpel hoop ik) gebruik van delegates:

je hebt een class LampController

edit:
was Lamp, maar die naam was niet handig gekozen en geeft verwarring

die iets voor je doet, laten we zeggen,
hij doet een lamp aan met een methode lampAan()
en uit met lampUit(), allebei maken ze gebruik van delegates ipv het zelf te doen
die class heeft ook een methode selecteerLamp( "lampnaam" ) om 'm wat zinvoller te maken

je hebt 3 classes (BouwLamp, SfeerLamp, Vuurtoren) die elk een ander soort lamp laten aangaan.
met allemaal een methode lampAan() en lampUit()
(naam hoeft niet hetzelfde te zijn, maar dat is voor nu wel duidelijker)

je hebt 2 buttons "aan" en "uit"

door middel van het delegate-gebeuren hoef je nooit meer de code voor het click-event van de buttons aan te passen om een andere lamp of meerdere lampen (met een MulticastDelegate ) aan/uit te laten gaan.
(het enige wat je in die event handlers hoeft te doen is LampController.lampAan() of LampController.lampUit() )

voordelen:
- LampController hoeft niet te weten hoe een lamp aan/uit gaat
- de buttons hoeven niet te weten welke lamp(en) aan of uit moet(en).
- welke lampen aan en uit gaan is makkelijk runtime aan te passen.
- BouwLamp, SfeerLamp en Vuurtoren hoeven geen geen subclass van LampController te zijn
- BouwLamp, SfeerLamp en Vuurtoren hoeven niet dezelfde interface te implementeren als LampController , alleen de method-signature moet hetzelfde zijn (niet iedereen is het erover eens dat dit een voordeel is, tis iig flexibeler)

[ Voor 8% gewijzigd door Verwijderd op 24-01-2005 23:15 ]

[prototype]

Deze manier van compositie dmv delegeren is natuurlijk niets mis mee, mits verstandig gebruikt. Het gebruik van dergelijke technieken coupled classen met elkaar hardcoded; dit is opzich ook de bedoeling in eerste instantie, maar kan grote gevolgen met zich meedragen vooral bij de structuur. Een classe heeft oppeens allemaal 'has-a' relaties, en daarmee ook meer dependencies. Een kleine refactoractie in een dergelijke classe kan het hele gecomposite classe in elkaar laten denderen (danwel meer), in dat 't niet meer de gewenste waarden geeft bv. Je hardcode namelijk in feite classenrelaties, en of dat wenselijk is is de vraag. Mij is altijd aangeleerd om de Law of Demeter(decoupling) te gebruiken om spaghetti code (dat ook 't resultaat kan worden van teveel delegeren) te voorkomen. Natuurlijk komt 't gewoon neer op verstandig gebruik en vaak kan je 't ook niet uit de weg, een AdapterPattern is bv een voorbeeld daarvan waarbij een specifieke classe met een bepaalde interface B z'n werking delegeert aan een gedelegeerd object met interface A.

Wat betreft het verhaal hierboven mij, van belang is dat je in dit soort situaties een interface implementeert voor het type Lamp. BouwLamp, SfeerLamp en Vuurtoren implementeren deze interface dan, zo weet je in IEDER GEVAL dat elk van deze lampen methoden implementeren waarvan de signatuur staat gespecificeerd in 't interface. Zodoende is BouwLamp subtype van Lamp, en dit geld ook voor de rest van de lampen. Bij 't delegaten kan je dan een supertype hardcoden lamp; BouwLamp, SfeerLamp en Vuurtoren geven hier gehoor aan. Dit is wat anders dan dat BouwLamp een subclasse zou zijn van Lamp in de zin dat een BouwLamp je dan 2 classen hebt gecoupled, op mijn manier ken je 't alleen type(n) toe en dwing je de classen die er naar luisteren af om bepaalde methoden te implementeren. Zo zou je Vuurtoren niet alleen als Lamp (lichtbron) kunnen beschouwen, maar ook als een gebouw. Je kan dan deze classe specifiek ook een interface Gebouw laten implementeren. Alles blijft nog gewoon werken alleen heb je ook nog gezegd dat Vuurtoren van het type Gebouw is naast Lamp, en dat 't ook uiteraard evt gespecificeerde methoden van Gebouw moet implementeren.
Ik hoop dat je er nog wat uit kan opmaken, iig een notie dat interfaces in dit verband erg belangrijk zijn.

[whoami]

Verwijderd schreef op maandag 24 januari 2005 @ 18:42:

offtopic:
een static getInstance() methode waarmee je een singleton tevoorschijn tovert is ernstig statefull hoor

Mjah, het is in die zin statefull dat je singleton iedere keer dezelfde instance teruggeeft.
Echter, ik zie dit anders dan gewone, niet - static classes/members.

voorbeeld van een zinvol (mwahh iig duidelijk en simpel hoop ik) gebruik van delegates

Ik snap hier ook niet waarom je dit niet oplost dmv een interface ?
Waarom geen 3 classes 'lamp' die elk die Lamp interface implementeren ?

Waarom is het een voordeel dat die specifieke lampen geen subclass van lamp hoeven te zijn ? IMO is het een nadeel; als je wel een subtype van lamp zijn; volgens mij maak je zo je ontwerp veel te rommelig.

[Verwijderd]

@ prototype
hoezo hardcoden? je gebruikt een addressof van een runtime instance methode als delegate
en dat een refactorisatie meteen de boel in duigen laat vallen klopt niet
de methode signature moet nog steeds exact hetzelfde zijn om te kunnen delegeren.

en dependencies zijn er juist minder omdat je niks te maken hebt met inheritance of interfaces.
Volgens mij verwar jij de VB delegate class met het composite of adapter patroon.
VB delegates zijn meer pointers zoals je in C of C++ hebt en zitten meer in het gebied van een taal feature, dan dat het een abstract model/patroon ding is (dat je de AddressOf operator moet gebruiken is een wel heel duidelijke hint in die richting)

delegates moet je zien als een goed hulpmiddel bij het efficient implementeren van het Command patroon naar mijn idee (en ja, ik heb ook het witte/blauwe boek met de wit/blauwe touwtjes voor de mensen die hier niks van snappen zie hier, een must om te lezen voor iedere OO devver)


@ whoami m'n offtopic was niet echt serieus bedoeld, tis maar hoe je tegen de definitie van statefull/stateless aankijkt, is alles wat ik bedoelde te zeggen

en ik heb nu allemaal lampen als voorbeeld genomen en dan is subclassing of een interface idd de betere oplossing, maar ik had ook als delegerende methode Iets.aan() en Motor, Lamp, Vuurtje, en ManVrouwRelatie als delegates kunnen nemen, en dan worden subclasses en interfaces ineens een heel stuk lastiger te definieren.

en de bedoeling van m'n verhaal was het principe van delegates uitleggen en de voordelen vanuit het perspectief van delegates.
(en eerlijk gezegd ben ik ook voorstander van subclassing en vooral interfaces, al was het alleen al omdat de compiler dan meer van mijn fouten vangt, zodat ik veel minder hoef te debuggen, en laten we eerlijk zijn, debuggen sucks monkeyballs)

btw ik heb ff snel de demo gecode, om het voorbeeld met wat code te illustreren
een selfextracting zipje van een project gemaakt in VB.net 2005 express beta
kan eenieder hier downen

voor de lol moet je ook eens zoeken naar het if statement
dat selecteert welke lamp er aan of uit moet

spoiler:

die is er dus niet, alleen if-jes voor foutafvanging en
in 2 van de concrete lampen voor het zetten van de juiste state.

edit:

ik heb er nog even over zitten denken, en volgens mij zit het nut van delegates
niet zozeer in het makkelijk aan elkaar knopen van objecten
maar in het flexibel runtime veranderen van het gedrag
van 1 bepaald object zonder dat je
enorme if-bomen of switch statements in hoeft te bouwen
een hele goede toepassing van delegates is te vinden in event-handlers van b.v. buttons
met het gebruik van delegates kan je heel makkelijk de functie van een klik op een button veranderen zonder dat de code die je daarvoor moet schrijven uit de klauwen loopt of inefficient wordt

[ Voor 84% gewijzigd door Verwijderd op 24-01-2005 22:53 ]

[prototype]

Verwijderd schreef op maandag 24 januari 2005 @ 21:13:
@ prototype
hoezo hardcoden? je gebruikt een addressof van een runtime instance methode als delegate
en dat een refactorisatie meteen de boel in duigen laat vallen klopt niet
de methode signature moet nog steeds exact hetzelfde zijn om te kunnen delegeren.

Ik neem aan dat adressoff(vb.net) vergelijkbaar is met instanceof (java/c#), maar dat is juist het hele punt dat ik wil maken. Je kan een dergelijk grapje als subtype switchen alleen gebruiken als er een supertype bekend is die je dan hardcode, jij doet dit dmv inheretence en de superclasse opgeven als referencetype, dat KAN wenselijk zijn maar ik snap niet waarom je dit niet met een interface oplost omdat je hier duidelijk doelt op typen die wel onder dezelfde noemer KUNNEN vallen maar niet per definitie HOEVEN (zie mijn voorbeeld over vuurtoren ook als gebouw zijnde). JUIST door het maken van een interface VERPLICHT je een subtype om dezelfde signatuur te hanteren van een van z'n supertypen. Als jij geen dergelijke methode hanteert, wat ik dus wel zo interpreteer, kan het hele gebeuren in elkaar vallen bij refactoren omdat ik geen interface heb die mij niet duidelijk oplegt dat ik een method met een dergelijk signatuur MOET implementeren. Nu kan dat wel met abstracte classen, maar ik vind dat in dit geval niet handig bij het lamp voorbeeld met name doelende op het vuurtoren voorbeeld dat zowel als Gebouw als Lamp behandeld zou kunnen worden met interfaces.

en dependencies zijn er juist minder omdat je niks te maken hebt met inheritance of interfaces.

Je hebt nu te maken met "has a" relatie, waarmee een composite instantie afhankelijk is van een of meer encapsulated instanties. Dit is wel degelijk een dependency. Dat laatste argument ben ik ook niet mee eens, dit gebeuren heeft juist totaal te maken met interfaces, anders kan je niet delegeren als de signatuur niet bekend is.

Volgens mij verwar jij de VB delegate class met het composite of adapter patroon.
VB delegates zijn meer pointers zoals je in C of C++ hebt en zitten meer in het gebied van een taal feature, dan dat het een abstract model/patroon ding is (dat je de AddressOf operator moet gebruiken is een wel heel duidelijke hint in die richting)

Ik wist niet dat delegeren anders was in VB.net , ik kalk alleen wat ik dus heb opgemaakt uit 't blauwwitte GoF boekje en dat is dat delegeren een van de steunpilaren is bij composite en adapter patroon. Ik ben verder niet bekend met VB.net, meer C#/java maar dat zou los moeten staan van 't concept delegeren.

[ Voor 14% gewijzigd door prototype op 24-01-2005 23:30 ]

[whoami]

Verwijderd schreef op maandag 24 januari 2005 @ 21:13:

edit:
ik heb er nog even over zitten denken, en volgens mij zit het nut van delegates
niet zozeer in het makkelijk aan elkaar knopen van objecten
maar in het flexibel runtime veranderen van het gedrag
van 1 bepaald object zonder dat je
enorme if-bomen of switch statements in hoeft te bouwen
een hele goede toepassing van delegates is te vinden in event-handlers van b.v. buttons
met het gebruik van delegates kan je heel makkelijk de functie van een klik op een button veranderen zonder dat de code die je daarvoor moet schrijven uit de klauwen loopt of inefficient wordt

Waarom zou je dat ook niet kunnen verkrijgen dmv inheritance / interfaces & polymorphisme?

[whoami]

Verwijderd schreef op maandag 24 januari 2005 @ 21:13:
en dependencies zijn er juist minder omdat je niks te maken hebt met inheritance of interfaces.

Dmv een interface leg je een contract vast; op zich heeft dat niet zozeer met dependencies tussen klassen te maken.

delegates moet je zien als een goed hulpmiddel bij het efficient implementeren van het Command patroon naar mijn idee (en ja, ik heb ook het witte/blauwe boek met de wit/blauwe touwtjes voor de mensen die hier niks van snappen zie hier, een must om te lezen voor iedere OO devver)

Imo moet je delegates eerder zien als een optie om het observer patroon te implementeren.

en ik heb nu allemaal lampen als voorbeeld genomen en dan is subclassing of een interface idd de betere oplossing, maar ik had ook als delegerende methode Iets.aan() en Motor, Lamp, Vuurtje, en ManVrouwRelatie als delegates kunnen nemen, en dan worden subclasses en interfaces ineens een heel stuk lastiger te definieren.

Motor Lamp, Vuurtje zouden dan ook niet dezelfde interface moeten implementeren, want het zijn functioneel andere dingen.

[Verwijderd]

prototype schreef op maandag 24 januari 2005 @ 23:07:
[...]
Ik neem aan dat adressoff(vb.net) vergelijkbaar is met instanceof (java/c#),

nee dat is het helemaal niet, AddressOf wil zeggen geheugenadres waar deze methode op dit moment te vinden is, en heeft niks gemeen met instanceof die het type checkt,

k wist niet dat delegeren anders was in VB.net , ik kalk alleen wat ik dus heb opgemaakt uit 't blauwwitte GoF boekje en dat is dat delegeren een van de steunpilaren is bij composite en adapter patroon. Ik ben verder niet bekend met VB.net, meer C#/java maar dat zou los moeten staan van 't concept delegeren.

dat bedoelde ik niet, wat ik bedoelde was dat je de VB delegate class misschien verwarde met het patroon van delegeren. en dat doe je ook omdat je aannam dat AddressOf ongeveer hetzelfde doet als instanceof in java

whoami schreef op maandag 24 januari 2005 @ 23:15:
Waarom zou je dat ook niet kunnen verkrijgen dmv inheritance / interfaces & polymorphisme?

kan ook, maar de truuk bij een VB delegate is juist dat je 1 bepaalde functie willekeurig waar dan ook vandaan kan plukken. (en ja, dat is eng,evil enz.. ben ik helemaal met je eens)

whoami schreef op maandag 24 januari 2005 @ 23:20:
Motor Lamp, Vuurtje zouden dan ook niet dezelfde interface moeten implementeren, want het zijn functioneel andere dingen.

dat bedoelde ik ook

whoami schreef op maandag 24 januari 2005 @ 23:20:
Imo moet je delegates eerder zien als een optie om het observer patroon te implementeren.

is eigenlijk hetzelfde maar dan anders voor allebei kan je delegates gebruiken,
Command, een controller heeft een lijst met delegates voor commands die uitgevoerd kunnen worden
Observer, een lijst met delegates voor objecten die genotificeert moeten worden.

[ Voor 86% gewijzigd door Verwijderd op 24-01-2005 23:59 ]

[prototype]

Verwijderd schreef op maandag 24 januari 2005 @ 23:34:
[...]

nee dat is het helemaal niet, AddressOf wil zeggen geheugenadres waar deze methode op dit moment te vinden is, en heeft niks gemeen met instanceof die het type checkt,


[...]

dat bedoelde ik niet, wat ik bedoelde was dat je de VB delegate class misschien verwarde met het patroon van delegeren. en dat doe je ook omdat je aannam dat AddressOf ongeveer hetzelfde doet als instanceof in java

Right, ik was toch van mening dat we het hier over de pattern hadden, voornamelijk omdat ik whoami's code sample/replies heb gelezen. ik google meteen op VB delegate class. Ik ben benieuwd in hoeverre dit anders is dan de pattern , of laat ik het zo zeggen, in hoeverre het voordeliger/nadeliger is, aangezien ik van mening dat de probleemstelling prima met de pattern opgelost kan worden.

Verwijderd schreef op maandag 24 januari 2005 @ 23:34:
[...]

kan ook, maar de truuk bij een VB delegate is juist dat je 1 bepaalde functie willekeurig waar dan ook vandaan kan plukken. (en ja, dat is eng,evil enz.. ben ik helemaal met je eens)

aha, interessant ... en dat is wenselijker tov bovengenoemde alternatieven? ...

[ Voor 39% gewijzigd door prototype op 24-01-2005 23:54 ]

[Verwijderd]

prototype schreef op maandag 24 januari 2005 @ 23:46:
aha, interessant ... en dat is wenselijker tov bovengenoemde alternatieven? ...

tis makkelijker (als in sneller geimplementeerd en je hoeft van te voren niet zoveel na te denken over je design) dat wel........ maar of het nou wenselijker is.... dat hangt helemaal van het design af waarin je het gebruikt, de potentie van grof misbruik is iig duidelijk aanwezig

en zoals ik al eerder zei, delegates zijn twee handen op 1 buik met (gui) event-handlers
en lijken een beetje op functors in java met dat verschil dat je een delegate uit een bestaande class of instance plukt en verpakt als object en een functor een eigen losstaande class is

[ Voor 41% gewijzigd door Verwijderd op 25-01-2005 00:22 ]