[C#] Override en Return type?

[Verwijderd]

Ik heb voor mijn project een aantal classes gemaakt die de communicatie met een SQL Server database afhandelen. Het werkt allemaal prima, maar nu moet ik vanuit de rest van mijn programma met die classes werken en ik loop daarbij tegen een aantal problemen aan.

Het gaat om de volgende classes:

AlbumsDB
MoviesDB
PlaylistDB
ShortMoviesDB
SongsDB

Al deze 5 classes inheriten van een algemene class met de naam: Database. Nu heb ik op deze class een viertal virtual functies gedefenieërd te weten:

code:

public virtual SqlDataReader GetList() {}
public virtual SqlDataReader GetList(bool includeadult) {}
public virtual SqlDataReader GetList(bool includeadult, bool movies) {}
public virtual DatabaseDetails GetDetails(Guid databaseid) {}

Daarnaast zijn er nog de volgende vijf classes:

AlbumDetails
MovieDetails
PlaylistDetails
ShortMovieDetails
SongDetails

En deze vijf classes inheriten van de class DatabaseDetails.

Op de 5 DB classes worden de functies GetList en GetDetails overriden. Het probleem is echter dat bijvoorbeeld de functie GetDetails op de class AlbumsDB een object van het type AlbumDetails moet teruggeven. Nu blijkt echter dat het return type niet kan veranderen als je een functie override. Dus ik begrijp nu niet helemaal hoe ik dit moet implementeren. Iemand ideeën of mensen die me op weg kunnen helpen?

[Alarmnummer]

1) je zou kunnen gaan casten
2) gebruik maken van polymorfisme. Dit kan alleen wel erg 'onduidelijk' worden in jouw geval
3) gebruik maken van geparametriseerde polymorfisme (kan je wel een beta versie van ophalen voor .NET)
4) covariante return types (een functie overriden met een minder ruim return type). Ik geloof niet dat dat in standaard .NET kan en ik weet niet of dit is toegevoegd aan die generics beta.


Ik zou dus gewoon even gaan casten

[ Voor 20% gewijzigd door Alarmnummer op 22-11-2002 15:20 ]

[Verwijderd]

Alarmnummer schreef op 22 november 2002 @ 15:16:
1) je zou kunnen gaan casten
2) gebruik maken van polymorfisme. Dit kan alleen wel erg 'onduidelijk worden in jouw geval'
3) gebruik maken van geparametriseerde polymorfisme (kan je wel een beta versie van ophalen voor .NET)
4) covariante return types (een functie overriden met een minder ruim return type). Ik geloof niet dat dat in standaard .NET kan en ik weet niet of dit is toegevoegd aan die generics beta.


Ik zou dus gewoon even gaan casten

Ehm, mjah, dat betekent dus dat het return type van elke GetDetails methode gewoon DatabaseDetails wordt. Vervolgens zou ik dan voor de buitenwereld steeds moeten casten naar het goede object.

[Alarmnummer]

Idd. Maar je zou ook kunnen kijken naar generics.

vb:

Java:

class Database<D extends DbDetails>{
        virtual D getDetails();
}

//vb gebruik maken.
Database<AlbumDetails> d = new Database<AlbumDetails>();
AlbumDetails a = d.getDetails();

Database<MovieDetails> d2 = new Database<MovieDetails>();
MovieDetails m = d2.getDetails();

[ Voor 20% gewijzigd door Alarmnummer op 22-11-2002 15:26 ]

[Verwijderd]

Alarmnummer schreef op 22 November 2002 @ 15:25:
Idd. Maar je zou ook kunnen kijken naar generics.

vb:

Java:

class Database<D extends DbDetails>{
        virtual D getDetails();
}

//vb gebruik maken.
Database<AlbumDetails> d = new Database<AlbumDetails>();
AlbumDetails a = d.getDetails();

Database<MovieDetails> d2 = new Database<MovieDetails>();
MovieDetails m = d2.getDetails();

Ehmz, dit volg ik niet helemaal geloof ik. Misschien omdat 't er niet in C# bij staat .

[whoami]

generics zijn nog niet geimplementeerd in .NET.

Verder zou ik ook voor de optie van het casten gaan. (Ofwel kun je ook nog eens je class-design herbekijken);

[Alarmnummer]

Je kan een upgrade ophalen voor .NET waarmee generics toegevoegd worden. Met generics kun je op een hele mooie manier code inlassen en geeft je de mogelijkheid om dus beter code te re-usen. Verder weet je wel wat polymorfisme is. Maar er zijn nog andere vormen van polymorfisme. De polymorfisme die jij kent ontstaat door overerving, maar je hebt ook geparametriseerde polymorisme (generics).

[Verwijderd]

Alarmnummer schreef op 22 November 2002 @ 15:29:
Je kan een upgrade ophalen voor .NET waarmee generics toegevoegd worden. Met generics kun je op een hele mooie manier code inlassen en geeft je de mogelijkheid om dus beter code te re-usen. Verder weet je wel wat polymorfisme is. Maar er zijn nog andere vormen van polymorfisme. De polymorfisme die jij kent ontstaat door overerving, maar je hebt ook geparametriseerde polymorisme (generics).

Nou jah, okeej, het werkt nu iig zoals ik 't wil hebben . Misschien dat ik al die andere dingen ooit nog eens leer . Misschien bij Java of zo, op school. Ben nog maar amateur programmeur, dus heb nog veel te leren .

Bedankt voor de reacties iig. Nu kan ik weer verder .

[ Voor 5% gewijzigd door Verwijderd op 22-11-2002 15:31 ]

[whoami]

offtopic:
Welke upgrade is dat dan wel?
Waar heb jij dat gezien? Het laatste dat ik gezien heb ivm generics is een document met daarin een voorstel over hoe ze het zouden implementeren. 't Was eigenlijk nog meer een RFC.

[Alarmnummer]

whoami schreef op 22 November 2002 @ 15:31:

offtopic:
Welke upgrade is dat dan wel?
Waar heb jij dat gezien? Het laatste dat ik gezien heb ivm generics is een document met daarin een voorstel over hoe ze het zouden implementeren. 't Was eigenlijk nog meer een RFC.

http://research.microsoft.com/projects/clrgen/
Gyro dus

[Verwijderd]

Ehm, nu heb ik toch nog even een vraagje. Ik heb namelijk die drie GetList methoden gedefinieert, maar als ik nu eerst een variable met de naam db van 't type Database maak en vervolgens die variable een waarde geef met new AlbumsDB(), new MoviesDB(), ... in een switch structuur en ik vervolgens db.GetList(<bool>, <bool>) wordt dus alleen de methode van de Database class gepakt.

[Alarmnummer]

Door polymorfisme wordt de juiste methode implementatie gekozen.

[whoami]

Heb je die getlist methoden wel ge-overrided in AlbumsDB, MoviesDB etc?
Is die method virtual in Database?
Erven AlbumsDB en MoviesDB over van Database?

[Verwijderd]

whoami schreef op 22 November 2002 @ 15:43:
Heb je die getlist methoden wel ge-overrided in AlbumsDB, MoviesDB etc?
Is die method virtual in Database?
Erven AlbumsDB en MoviesDB over van Database?

Ehmz:

code:

public class AlbumsDB : Database
     public override SqlDataReader GetList()
public class MoviesDB : Database
     public override SqlDataReader GetList(bool includeAdult)
public class Database
     public virtual SqlDataReader GetList() { return null; }
     public virtual SqlDataReader GetList(bool includeadult) { return null; }
     public virtual SqlDataReader GetList(bool includeadult, bool movies) { return null; }

Dat klopt toch?

[Alarmnummer]

Het is een beetje vreemd dat er wel een implementatie bij een virtuele functie zit. Ik heb dit ook gezien in c++ en ik vind het erguh lelijk. Verwijder die implementatie dus even en maak een implementatie bij AlbumDb en bij MovieDb. (Een virttuele functie (een functie zonder implementatie), mag dus geen implementatie hebben in principe).

En verder zou ik ook veel meer werken met interfaces ipv abstracte classes. Je zou in jouw geval van die db een interface kunnen maken.

[ Voor 17% gewijzigd door Alarmnummer op 22-11-2002 15:51 ]

[Verwijderd]

Alarmnummer schreef op 22 November 2002 @ 15:49:
Het is een beetje vreemd dat er wel een implementatie bij een virtuele functie zit. Ik heb dit ook gezien in c++ en ik vind het erguh lelijk. Verwijder die implementatie dus even en maak een implementatie bij AlbumDb en bij MovieDb. (Een virttuele functie (een functie zonder implementatie), mag dus geen implementatie hebben in principe).

Je bedoeld dat het vreemd is dat die virtuele functies wel iets moeten doen, in dit geval dus return null?

[Alarmnummer]

Verwijderd schreef op 22 November 2002 @ 15:50:
[...]


Je bedoeld dat het vreemd is dat die virtuele functies wel iets moeten doen, in dit geval dus return null?

Idd. Je zegt bij die virtuele functie dat de implementatie bij een kinder class staat, en toch zet je daar een implementatie neer. Bij java is dat gewoon niet mogelijk, en ik imho vind ik het zeer lelijk staan bij c#

[Verwijderd]

Alarmnummer schreef op 22 November 2002 @ 15:52:
[...]

Idd. Je zegt bij die virtuele functie dat de implementatie bij een kinder class staat, en toch zet je daar een implementatie neer. Bij java is dat gewoon niet mogelijk, en ik imho vind ik het zeer lelijk staan bij c#

Mjah, als ik het weghaal zegt ie: not all code paths return a value.

[Alarmnummer]

Dat klopt, je moet dan wel ff een impementatie van die functies maken bij FilmDb en AlbumDb.

dus {return null;} in jouw geval

[edit] waarom staat die 17% er nou weer??
en nu 32%

[ Voor 36% gewijzigd door Alarmnummer op 22-11-2002 15:55 ]

[Verwijderd]

Alarmnummer schreef op 22 november 2002 @ 15:54:
Dat klopt, je moet dan wel ff een impementatie van die functies maken bij FilmDb en AlbumDb.

dus {return null;} in jouw geval

Oh, dus ik moet alle virtuele functies in de class Database overriden in m'n inherited classes zonder dat ik ze gebruik?

[whoami]

Alarmnummer schreef op 22 november 2002 @ 15:49:
Het is een beetje vreemd dat er wel een implementatie bij een virtuele functie zit. Ik heb dit ook gezien in c++ en ik vind het erguh lelijk. Verwijder die implementatie dus even en maak een implementatie bij AlbumDb en bij MovieDb. (Een virttuele functie (een functie zonder implementatie), mag dus geen implementatie hebben in principe).

En verder zou ik ook veel meer werken met interfaces ipv abstracte classes. Je zou in jouw geval van die db een interface kunnen maken.

Euheuh. Een virtuele functie mag moet een implementatie hebben. Dat is handig als je ook gelijke implementatie wilt overerven naar de childclasses. Maar in dit geval is de implementatie in die virtuele functies (die return null) dus wel degelijk overbodig, en zouden ze beter abstract gemaakt worden.
Een abstracte functie mag geen implementatie hebben.

[whoami]

Verwijderd schreef op 22 November 2002 @ 15:53:
[...]


Mjah, als ik het weghaal zegt ie: not all code paths return a value.

Dan moet je ze nog abstract maken ipv virtual.

[Alarmnummer]

Het woord overriden is niet correct. Er is namelijk niets om te overriden, want je hebt hem nog nergens geimplementeerd. Maar verder moet je idd een implementatie leveren bij de kinder classes.

[Verwijderd]

whoami schreef op 22 November 2002 @ 15:56:

[...]

Dan moet je ze nog abstract maken ipv virtual.

Ehmz, ben nu even in de war. Abstract en virtual, wat is nou wat en wat houdt 't in?

[whoami]

Verwijderd schreef op 22 november 2002 @ 15:58:
[...]


Ehmz, ben nu even in de war. Abstract en virtual, wat is nou wat en wat houdt 't in?

Een abstracte functie is een virtuele functie zonder implementatie.

code:

public abstract void ThisIsAbstract();
public virtual void ThisIsVirtual()
{
   ... do something
}

[ Voor 18% gewijzigd door whoami op 22-11-2002 15:59 ]

[Verwijderd]

whoami schreef op 22 November 2002 @ 15:58:

[...]


Een abstracte functie is een virtuele functie zonder implementatie.

code:

public abstract void ThisIsAbstract();
public virtual void ThisIsVirtual()
{
   ... do something
}

Ah, okeej, maar een abstracte functie kan alleen voorkomen in een abstracte class zie ik nu net. En een abstracte class is een class zonder implementatie?

[Alarmnummer]

En wat is het verschil tussen een gewone functie en een virtuele functie met implementatie? Ze kunnen allebei overriden worden, dus what`s the difference? Trouwens bij c++ heeft virtual volgens mij dezelfde betekenis als abstract bij java. (Afgezien dat je dus een implementatie mag leveren bij c++)

[whoami]

Verwijderd schreef op 22 November 2002 @ 16:00:
[...]


Ah, okeej, maar een abstracte functie kan alleen voorkomen in een abstracte class zie ik nu net. En een abstracte class is een class zonder implementatie?

Een abstracte class kan wel functies hebben met een implementatie, maar je kunt geen objecten instantieren van een abstracte class. Je zult dus moeten een class inheriten van die abstracte class.

[Verwijderd]

Ehmz, nu die functies allemaal abstract zijn moet ik ze dus wel implementeren in m'n inherited classes, maar dan hou ik hetzelfde probleem houden, want die functies hoeven in dat geval niks te doen. Of kan ik dan iets van return GetList(); in die functie gooien?

[whoami]

Alarmnummer schreef op 22 november 2002 @ 16:00:
En wat is het verschil tussen een gewone functie en een virtuele functie met implementatie? Ze kunnen allebei overriden worden, dus what`s the difference? Trouwens bij c++ heeft virtual volgens mij dezelfde betekenis als abstract bij java. (Afgezien dat je dus een implementatie mag leveren bij c++)

Met een 'gewone' functie kun je geen polymorphisme afdwingen afaik.
(overriden en polymorphisme is ook heel iets anders).

In C++ is virtual en abstract niet hetzelfde. In C++ heb je afaik virtual functies en pure virtuele functies. Die pure virtuele functies zijn gelijk aan abstract in Java/C#:

code:

// Virtual functie
virtual void MyFunc()
{
}
// pure virtuele
virtual void Myfunc() = 0;

[whoami]

Verwijderd schreef op 22 november 2002 @ 16:02:
Ehmz, nu die functies allemaal abstract zijn moet ik ze dus wel implementeren in m'n inherited classes, maar dan hou ik hetzelfde probleem houden, want die functies hoeven in dat geval niks te doen. Of kan ik dan iets van return GetList(); in die functie gooien?

Ik volg je hier niet.

Wat heb je nu?

[Alarmnummer]

whoami schreef op 22 november 2002 @ 16:03:

[...]


Met een 'gewone' functie kun je geen polymorphisme afdwingen afaik.
(overriden en polymorphisme is ook heel iets anders).

Nee hoor.

code:

abstract class Fruit{
    public void eet( print("hap hap");
}

class Appel extends Fruit{
   public void eet(print("ff schillen, en dan hap hap");
}

class Peer extends Fruit{
    public void eet(print("grrrr een peer.. ");
}

Fruit p = new Peer();
p.eet();
//grrr een peer

[ Voor 8% gewijzigd door Alarmnummer op 22-11-2002 16:07 ]

[Verwijderd]

whoami schreef op 22 November 2002 @ 16:05:

[...]

Ik volg je hier niet.

Wat heb je nu?

Nou, als ik nu de boel compileer krijg ik de volgende errors:

code:

'PES.Database.AlbumsDB' does not implement inherited abstract member 'PES.Database.Database.GetList(bool)'
'PES.Database.AlbumsDB' does not implement inherited abstract member 'PES.Database.Database.GetList(bool, bool)'
...

Dus blijkbaar moet ik die methoden altijd implementeren in elke class. Maar kan ik dan bijvoorbeeld het volgende stukje code schrijven:

code:

public override SqlDataReader GetList(bool includeadult) 
{
    return GetList();
}

[whoami]

Alarmnummer schreef op 22 November 2002 @ 16:06:
[...]

Nee hoor.

code:

abstract class Fruit{
    public void eet( print("hap hap");
}

class Appel extends Fruit{
   public void eet(print("ff schillen, en dan hap hap");
}

class Peer extends Fruit{
    public void eet(print("grrrr een peer.. ");
}

Fruit p = new Peer();
p.eet();
//grrr een peer

Maar in jouw voorbeeld ga je ook niet gaan overriden.
Trouwens, als ik iets dergelijks doe in C#, dan krijg ik als resultaat:
"Ik eeet fruit"

code:

class Fruit
{
   public void Eet()
   {
       Console.WriteLine("Ik eet fruit");
   }
}

class Peer : Fruit
{
   public void Eet();
   {
       Console.WriteLine ("Ik eet peer");
    }
}

Fruit f = new Peer();
f.eet();

Ga ik echter die functie in Fruit virtual maken en in Peer overriden, dan krijg ik:

ik eet peer

[Alarmnummer]

Als ik eerlijk ben zit ik ook even bij mijn voorbeeld in twijfel. Maar ik override ook bijna geen functies meer tegenwoordig

[ Voor 33% gewijzigd door Alarmnummer op 22-11-2002 16:18 ]

[whoami]

Neem weg die twijfel en test het uit.

[Alarmnummer]

whoami schreef op 22 november 2002 @ 16:22:
Neem weg die twijfel en test het uit.

Heeft geen java geinstalleerd

[whoami]

Verwijderd schreef op 22 november 2002 @ 16:09:
[...]


Nou, als ik nu de boel compileer krijg ik de volgende errors:

code:

'PES.Database.AlbumsDB' does not implement inherited abstract member 'PES.Database.Database.GetList(bool)'
'PES.Database.AlbumsDB' does not implement inherited abstract member 'PES.Database.Database.GetList(bool, bool)'
...

Dus blijkbaar moet ik die methoden altijd implementeren in elke class. Maar kan ik dan bijvoorbeeld het volgende stukje code schrijven:

code:

public override SqlDataReader GetList(bool includeadult) 
{
    return GetList();
}

Je moet alle abstracte methods idd in de childs gaan uitwerken.
Of jouw voorbeeld mogelijk is: wil je het resultaat van een andere GetList() (zonder parameters) returnen : als die GetList() een implementatie heeft lijkt het me wel mogelijk ja.
Maar probeer het ff uit.

[whoami]

Alarmnummer schreef op 22 November 2002 @ 16:22:
[...]

Heeft geen java geinstalleerd

Een javahova zonder Java.

[mbravenboer]

Het voorbeeld van Alarmnummer werkt natuurlijk wel in Java: daar zijn methoden standaard virtual.

[Alarmnummer]

whoami schreef op 22 november 2002 @ 16:24:

[...]


Een javahova zonder Java.

Noem me maar hova dan voortaan

[whoami]

mbravenboer schreef op 22 november 2002 @ 16:24:
Het voorbeeld van Alarmnummer werkt natuurlijk wel in Java: daar zijn methoden standaard virtual.

Owja.... Ik heb eens in een ver verleden zoiets gelezen idd....
Maar, hoe ga je dan non-virtuele functies in Java definieren? Of is dat niet mogelijk?
Maar heeft Alarmnummer in zijn voorbeeld dan hoedanook geen 'override' keyword vergeten?

[ Voor 11% gewijzigd door whoami op 22-11-2002 16:25 ]

[Alarmnummer]

whoami schreef op 22 November 2002 @ 16:25:

[...]


Owja.... Ik heb eens in een ver verleden zoiets gelezen idd....
Maar, hoe ga je dan non-virtuele functies in Java definieren? Of is dat niet mogelijk?

Als je bedoelt dat er niet meer overriden kan worden, kan je er final voorplakken.

aar heeft Alarmnummer in zijn voorbeeld dan hoedanook geen 'override' keyword vergeten?

Heeft nog nooit een override keyword gezien in java

[ Voor 19% gewijzigd door Alarmnummer op 22-11-2002 16:26 ]

[mbravenboer]

whoami: Maar, hoe ga je dan non-virtuele functies in Java definieren? Of is dat niet mogelijk?

Door final te gebruiken. Je kan dan in een subklasse echter niet even verder gaan met een 'nieuwe methode' met dezelfde naam zoals in C# wel kan.

[mbravenboer]

whoami: Maar heeft Alarmnummer in zijn voorbeeld dan hoedanook geen 'override' keyword vergeten?

Java kent (wellicht helaas) geen override keyword ...

[Verwijderd]

Lol, dat m'n topicje nog zoveel teweeg heeft gebracht .

[whoami]

mbravenboer schreef op 22 november 2002 @ 16:27:
[...]

Java kent (wellicht helaas) geen override keyword ...

Tja, als Java alle methods standaard als virtual aanziet, dan is een override keyword eigenlijk overbodig. (of niet soms?).
(Dat keyword zou anderszijds wel de duidelijkheid ten goede komen).

[ Voor 10% gewijzigd door whoami op 22-11-2002 16:36 ]

[Verwijderd]

whoami schreef op 22 November 2002 @ 16:23:

[...]

Je moet alle abstracte methods idd in de childs gaan uitwerken.
Of jouw voorbeeld mogelijk is: wil je het resultaat van een andere GetList() (zonder parameters) returnen : als die GetList() een implementatie heeft lijkt het me wel mogelijk ja.
Maar probeer het ff uit.

Mjah, op de één of andere manier vind ik het lelijk. Nu heb je dus in elke class drie methoden, waarvan je er maar één effectief gebruikt. Dat lijkt me een beetje overbodig allemaal .

[whoami]

Verwijderd schreef op 22 November 2002 @ 16:50:
[...]


Mjah, op de één of andere manier vind ik het lelijk. Nu heb je dus in elke class drie methoden, waarvan je er maar één effectief gebruikt. Dat lijkt me een beetje overbodig allemaal .

De vraag die je je dan kan stellen:
waarom heb jij 3 verschillende methoden als die allemaal hetzelfde doen?
(Of bedoel je nu die 3 methods uit de child classes?)
Die kunnen/mogen toch hetzelfde niet doen, want het gaat iedere keer over verschillende data.

[Alarmnummer]

Verwijderd schreef op 22 November 2002 @ 16:50:
[...]


Mjah, op de één of andere manier vind ik het lelijk. Nu heb je dus in elke class drie methoden, waarvan je er maar één effectief gebruikt. Dat lijkt me een beetje overbodig allemaal .

Op dit moment misschien wel, maar uiteindelijk ga je wel implementaties leveren. Zo heb jij het nu ontwerpen, en als je dan niet aan je ontwerp wilt houden kan je ontwerp je idd tegenwerken.

[Verwijderd]

whoami schreef op 22 November 2002 @ 16:52:
[...]


De vraag die je je dan kan stellen:
waarom heb jij 3 verschillende methoden als die allemaal hetzelfde doen?
(Of bedoel je nu die 3 methods uit de child classes?)
Die kunnen/mogen toch hetzelfde niet doen, want het gaat iedere keer over verschillende data.

Nou, het verschil is eigenlijk heel simpel. De functies werken met een Stored Procedure in een SQL Server Database. Alleen heeft bijvoorbeeld de Stored Procedure voor Playlists wel parameters nodig, terwijl bijvoorbeeld de Stored Procedure voor Albums geen parameters nodig heeft. Vandaar dus die drie verschillende methoden. Ze doen echt niet allemaal hetzelfde.

[mbravenboer]

whoami: Tja, als Java alle methods standaard als virtual aanziet, dan is een override keyword eigenlijk overbodig. (of niet soms?).

Mwah, niet helemaal: als je een methode wilt override in een subklasse moet de compiler nu zelf nog uitzoeken dat je dit bedoelt. Er kunnen twee dingen misgaan:

1) Je wilt helemaal geen methode overriden maar de methode bestaat al wel in een superklasse.
2) Je wilt een methode overriden maar je maakt een tikfout in de methode naam of in de parameters.


In beide gevallen lost het override keyword iets op: in het eerste geval kan de compiler waarschuwen dat je een methode override terwijl je dit niet bedoelt. In het tweede geval kan de compiler waarschuwen dat je niets override terwijl je dit wel bedoelde.

Dat keyword zou anderszijds wel de duidelijkheid ten goede komen.

Dat ook zeker .

[whoami]

Verwijderd schreef op 22 november 2002 @ 16:54:
[...]


Nou, het verschil is eigenlijk heel simpel. De functies werken met een Stored Procedure in een SQL Server Database. Alleen heeft bijvoorbeeld de Stored Procedure voor Playlists wel parameters nodig, terwijl bijvoorbeeld de Stored Procedure voor Albums geen parameters nodig heeft. Vandaar dus die drie verschillende methoden. Ze doen echt niet allemaal hetzelfde.

Hmm, als die methods een verschillende signature hebben, dan heeft het eigenlijk geen nut om ze te gaan overriden imho. Je gaat ze dan gewoon overloaden.

[whoami]

whoami schreef op 22 November 2002 @ 16:03:
[nohtml]
[...]
[/nohtml]

Met een 'gewone' functie kun je geen polymorphisme afdwingen afaik.
(overriden en polymorphisme is ook heel iets anders).

[nohtml]

Alarmnummer schreef op 22 november 2002 @ 16:06:
[...]

Nee hoor.

Om hier nog even op terug te komen.

Als ik

code:

class Fruit
{
    public void Eet()
    {
         Console.WriteLine ("Fruit");
    }
}

class Peer : Fruit
{
    public override void Eet()
    {
          Console.WriteLine ("peer");
    }
}

schrijf, dan krijg ik compiler-errors. Ik kan nl. die Eet method in Peer niet overriden omdat Eet in Fruit niet als virtual gedeclareerd werd.
Maar goed, hier kunnen we wellicht van 'taal-verwarring' spreken omdat Alarmnummer gewend is van in Java te werken en in Java alle methods blijkbaar standaard 'virtual' zijn en dus ook standaard 'geoverride' worden, waardoor dat proces eigenlijk een beetje verborgen wordt.