[C#] Hiding method from base class

[Jabbah]

Ik heb een class die afgeleid is van Hashtable. Hashtable heeft een methode Add(object key, object value)
Ik wil graag in mijn afgeleide class m'n eigen Add methode implementeren. Deze methode roept op zijn beurt de Hashtable.Add aan maar heeft wel andere parameters.
Nou wil ik graag de Hashtable.Add methode 'hiden' zodat de gebruiker alleen de nieuwe Add methode kan gebruiken.

Overriden wil niet want mijn Add heeft andere parameters. Een nieuwe Add methode maken met het 'new' keyword kan, maar hide de Hashtable.Add niet. In VB.NET heb je het Shadows keyword die precies doet wat ik wil, maar C# kent deze niet.

Iemand een idee?

[whoami]

In plaats van te inheriten, kan je gaan 'composen'.

Je maakt dan dus een custom collection class die een Hashtable member 'heeft' ipv een class te inheriten van Hashtable (en die dus eigenlijk een hashtable is).

Zo dus:

code:

class MyHashtableStuff
{
     private Hashtable    _innerCollection = new Hashtable();

     public int Add(string blaat,  MyClassType myObject, .... )
     {
           return _innerCollection.Add( blaat, myObject);
     }
      ....
}

[ Voor 42% gewijzigd door whoami op 29-11-2004 12:58 ]

[Jabbah]

Ah, dat is een mogelijkheid. Vergt wel wat herschrijfwerk.

Vreemd overigens dat C# geen equivalent kent van het Shadows keyword in VB. Zal ongetwijfeld een reden achter zitten..

[whoami]

In C# kan je ws het 'new' keyword gaan gemisbruiken voor dit doel. Maar imo is het evil en lelijk, en kan je beter de 'composition' methode gaan toepassen.

[pjvandesande]

whoami schreef op maandag 29 november 2004 @ 13:22:
In C# kan je ws het 'new' keyword gaan gemisbruiken voor dit doel. Maar imo is het evil en lelijk, en kan je beter de 'composition' methode gaan toepassen.

Was is er dan mis met het new -keyword. Er word wel voor gewaarschuuwd en alleen moet gebruiken als je weet wat je doet, maar we zitten hier in /14 en dat weten we hier wel.

De composition methode komt op hetzelfde neer, alleen ik dit juist een minder overzichterlijke methode.

[ Voor 14% gewijzigd door pjvandesande op 29-11-2004 13:34 ]

[riezebosch]

Kan je niet de Add-functie van Hashtable overnemen in je eigen afgeleide class, maar dan private en in je herschreven Add functie (met andere paramters) base.Add oid doen?

edit:

Moet je dan idd met "new" doen, anders kan je de functie uit de base-class niet private maken... Maar verder: wat is er dan mis mee?

[ Voor 31% gewijzigd door riezebosch op 29-11-2004 13:42 ]

[EfBe]

Shadows' functionaliteit zie je alleen terug in intellisense. Voor de rest zijn ze gelijk, en beide verbergen de base class method nooit, want je kunt altijd middels reflection bij de base' method (en terecht). (alleen heeft VB.NET's editor 'intelligentie' meegekregen dat hij het aanroepen van de base class method als 'fout' bestempelt, terwijl het gebruik van die dll in C# gewoon de aanroep van de base class toestaat. (ergo: vb.net is 'dom' bezig))

[ Voor 39% gewijzigd door EfBe op 29-11-2004 13:43 ]

[pjvandesande]

C#:

public class A
{
     public void Add(object obj)
     {
          ...
     }
}

public class B : A
{
     public new void Add(object obj)
     {
          ...
     }
}

Je kan dan altijd de base Add-method aanroepen met:

C#:

B foo = new B();
((A)foo).Add(new object());

Disclaimer: Questa kan nu even niet checken, maar dacht van wel.

[Jabbah]

Het 'new' keyword heeft geen zin hier, omdat deze alleen werkt als de parameters van de nieuwe methode gelijk zijn aan die van de base class. De methode proberen te hiden dmv deze private te maken in de afgeleide class gaat ook niet lukken.

Efbe: Weet je zeker dat Shadows alleen is ingebouwd voor de intellisense? Want de compiler geeft wel degelijk een foutmelding als ik de base.Add methode wil aanroepen terwijl de methode in de afgeleide class het Shadows keyword heeft.

[TlighT]

questa schreef op maandag 29 november 2004 @ 13:32:
[...]


Was is er dan mis met het new -keyword. Er word wel voor gewaarschuuwd en alleen moet gebruiken als je weet wat je doet, maar we zitten hier in /14 en dat weten we hier wel.

Het nadeel van shadowen van een method is dat je je object niet meer fatsoenlijk kunt downcasten aangezien je dan de method op de base klasse aanroept en niet die op je overgeerfde klasse.

Bijvoorbeeld wat ik ooit deed:

code:

public class MyNameValueCollection : NameValueCollection
{
   ...
   public new void Clear()
   {
      IsDirty = true;
      base.Clear();
   }

   public override void Set(string name, string value)
   {
      IsDirty = true;
      base.Set (name, value);
   }
   ...
}

public void DoeIets(NameValueCollection collection)
{
    ...
    collection.Clear();
    ...
}

MyNameValueCollection collection;
...
DoeIets(collection);
...
if (collection.IsDirty)
{
   // Huh, waarom wordt de IsDirty flag niet gezet???
}

En dat was nog terwijl ik mijn zelfgeschreven klasse wilde gebruiken *schaam* Stel je voor wanneer iemand anders je progsels gebruikt, die snapt er niks meer van (je krijgt dacht ik ook geen enkele waarschuwing).

[pjvandesande]

TlighT schreef op maandag 29 november 2004 @ 14:03:
[...]

Het nadeel van shadowen van een method is dat je je object niet meer fatsoenlijk kunt downcasten aangezien je dan de method op de base klasse aanroept en niet die op je overgeerfde klasse.

knip

En dat was nog terwijl ik mijn zelfgeschreven klasse wilde gebruiken *schaam* Stel je voor wanneer iemand anders je progsels gebruikt, die snapt er niks meer van (je krijgt dacht ik ook geen enkele waarschuwing).

Nee, hier moet je heel goed rekening mee houden, je moet ook goed weten waar je mee bezig bent en zeker niet zo klakkenloos gebruiken.

Ik gebruik het zelf ook niet, composen is dan een beteren oplossing, hiermee kan er niet mee gedowncast worden.

[D4Skunk]

5 seconden google

[TlighT]

D4Skunk schreef op maandag 29 november 2004 @ 14:37:
5 seconden google

Uit bovenstaande:

If any of this is starting to send chills down your spine, then good. It should. VB.NET and C# have both managed to add built-in support for violating one of the most sacred rules of object-oriented programming, that being the Liskov Substitution Principle. You may be unfamiliar with the name, but I bet you will immediately recognize the concept.

The Liskov Substitution Principle (spoken with an echo, or simply LSP as the "in crowd" calls it) was first stated by Barbara Liskov in 1988 ("Data Abstraction and Hierarchy," SIGPLAN Notices, 23,5 to be exact) and states that functions using references to base classes must be able to use objects of derived classes without knowing it. As a simple example, a method that acts upon a Shape object should be able to be passed a Circle object instead (assuming it inherits from Shape) and never know the difference. This just makes sense.

Dat bedoel ik dus ... dit is helemaal sneaky als je Java gewend bent waarin alle methods standaard virtual zijn behalve wanneer ze expliciet final gedeclareerd zijn.