Ist dort Weg für eine Klasse zu 'entfernen' Methoden, die es geerbt hat?

Ist es Weg für eine Klasse zu 'entfernen' Methoden, die es geerbt hat?

E. g. wenn ich nicht möchte, dass meine Klasse ToString() Methode kann ich etwas tun, so dass es nicht mehr verfügbar ist?

  • codinghorror.com/blog/2004/08/inherits-nothing.html
  • Dies ist bekannt als die "Refused Bequest" code smell: "eine Klasse, überschreibt eine Methode der Basisklasse in einer solchen Weise, dass der Vertrag von der Basis-Klasse wird nicht geehrt durch die abgeleitete Klasse". en.wikipedia.org/wiki/Code_smell
  • Es gibt keine Möglichkeit zum entfernen einer Methode. Wenn die Methode virtual (markiert mit virtual, abstract oder override), haben Sie Glück, weil der Autor von der Basisklasse erlaubt Ihnen zu entscheiden, das Verhalten der Methode. Man konnte es nichts zu tun, oder werfen eine Ausnahme (aber beachten Sie, dass diese brechen könnte die Basisklasse Erwartung, von Ihrer Methode, so würde es zu Problemen führen, in einigen Fällen). Wenn die Methode ist nicht virtuell, Sie können nicht viel tun. Verstecken Sie es mit einer anderen Methode ist eine sehr schlechte Idee (und nicht entfernen Sie es natürlich).
InformationsquelleAutor CJ7 | 2010-05-06
  1. 32

    Nein - das würde gegen Liskov ' s substitutionsprinzip. Sie sollten immer in der Lage, verwenden Sie eine Instanz von einem Untertyp, als ob es eine Instanz eines supertyps.

    Vergessen Sie nicht, dass ein Anrufer kann nur bewusst sein, Ihre Art "als" Basis-Typ oder eine Schnittstelle. Betrachten Sie diesen code:

    object foo = new TypeWithToStringRemoved();
foo.ToString();

    Haben würde, um zu kompilieren, wäre es nicht? Was würden Sie jetzt erwarten, dass passiert bei der Ausführung?

    Nun für ToString, GetHashCode, Equals und GetType es gibt keinen Weg, um zu vermeiden, dass Sie in den ersten Platz - aber in der Regel, wenn es gibt Methoden, die Sie möchten, auf "remove" von einer Basis geben, die vermuten lässt, dass Sie sollten nicht Erben es in den ersten Platz. Persönlich finde ich die Rolle der Vererbung ist etwas übertreiben in der Objekt-orientierten Programmierung: wo ist es sinnvoll es wirklich nützlich, aber im Allgemeinen bevorzuge ich die Komposition über Vererbung und Schnittstellen als eine form der Abstraktion eher als Basisklassen.

    • Du hast vollkommen Recht - es ist besonders gefährlich, um die ToString() Methode eine Ausnahme werfen. Es gibt eine Menge mehr in hidden Verwendungen von ToString() als die, die Sie zeigten (Aufruf direkt).
    • Aber sicher könnten Sie die new modifier ausblenden eines geerbten Mitglieds (und löst eine NotSupportedException aus, wie tanascius vorgeschlagen), ohne irgendwelche Prinzipien oder werfen unerwartete Ausnahmen.
    • Es wird immer unerwartet, wenn ein ToString() Aufruf eine exception wirft ...
    • Ich bin nicht speziell reden über ToString(). Sagen wir, Sie haben Ball Klasse, die eine virtuelle Bounce() Methode verwendet, die eine virtuelle BounceHeight - Eigenschaft, um zu arbeiten. Wenn Sie eine ConcreteBall Klasse, könnte man das überschreiben der BounceHeight Eigenschaft und geben 0 zurück, während new-ing die Bounce() - Methode und werfen einen NotSupportedException. So dass, wenn Sie eine Ball Verweis auf eine ConcreteBall Objekt Bounce() wird nicht werfen aber keinen Effekt haben wird (wie erwartet), während die aufrufende Bounce() auf einen Verweis auf ConcreteBall werfen und informativ sein (wie erwartet).
    • ConcreteBall sollte noch in der Lage sein zu hüpfen. Die Wirkung der Aufruf der Methode ist nur, dass nichts geschieht. Wenn ConcreteBall konnte nicht hüpfen, dann warum ist es, einen ball in den ersten Platz? Aufruf Bounce() auf ConcreteBall ist nicht wirklich ein außergewöhnlicher Fall.
    • In meiner Erfahrung, diese Art von Verhalten ist sehr verwirrend. Es führt zu Veränderungen, die look harmlos ("variable mehr allgemein") code unterbrechen. Nicht eine gute Idee, IMO.
    • Ich meinte ConcreteBall im Gegensatz zu RubberBall, nicht ConcereteBall im Gegensatz zu AbstractBall - habe ich erst jetzt erkannt, die mögliche Verwirrung, tut mir Leid. Jedenfalls war ich gerade dabei eine Seite, von der Gestaltung der Stream Klasse, wo Seek (und die anderen Methoden und Eigenschaften) werfen NotSupportedException wenn die konkrete Implementierung nicht unterstützt. Jon, ich Stimme zu, die Regel ist dies nicht die beste Idee (für Strom, würde ich gegangen für ISeekableStream, IWriteableStream, etc), aber mein Hauptpunkt ist, dass ich glaube nicht, dass die Antwort auf die OP-Frage ist ein straight-up 'Nein'.
    • Diese Antwort ist richtig, aber manchmal möchte ich einfach nur stehlen die Implementierung von jemand anderes s-Klasse für den export steht jedoch nur eine begrenzte Schnittstelle an. Dafür habe ich explizit den proxy-jede der Methoden, die ich will.
    • Yup, und das ist ein bisschen wie ein Schmerz - aber es bedeutet nicht, dass ein Missbrauch der Vererbung (und das Verfügbarmachen von Methoden, die Sie nicht wollen, zu entlarven), ist ein besserer Ansatz. Es wäre schön, wenn sich C# und Java hatte, bessere Unterstützung für mix-ins.
    • Yep. Ich mag die anonyme Einbettung von Go. Aber während ich wünschte, andere Sprachen hatte es, ich vermute, es würde überschneiden sich zu sehr mit den bestehenden Funktionen (wie Vererbung).

    InformationsquelleAutor Jon Skeet
  2. 18

    Können Sie werfen eine NotSupportedException aus, markieren Sie es als Veraltet und verwenden EditorBrowsable:

    [EditorBrowsable( EditorBrowsableState.Never )]
[Obsolete( "...", false )]
void YourMethod()
{
    throw new NotSupportedException( "..." );
}

    EDIT:

    Wie von anderen darauf hingewiesen: ich beschreibe einen Weg, um "deaktivieren" Methoden, aber Sie haben zu denken, sorgfältig, wo Sie wollen, um diese zu verwenden. Vor allem das werfen von Ausnahmen kann eine sehr gefährliche Sache.

    • Wenn Sie Ausnahme arguement von Veralteten Immobilie, Ihr code wird gut;-)
    • Nein, das sind zwei verschiedene strings ^^ Vielleicht sollten Sie sich unterscheiden, da die veraltet - Nachricht für einen Entwickler, während die Ausnahme Nachricht konnte er erreicht ein Benutzer? Naja, wohl nicht - zumindest sollte es nicht.
    • ok, Sie verteidigt;-)
    • Wenn Sie wirklich wollten, um deaktivieren Sie die Methode, wäre es nicht besser zu tun [Obsolete( "...", true )]? Dann der Aufruf der Methode zu einem compiler-Fehler, keine Ausnahme erforderlich.
    • Pro piedar finden Sie in der IsError Eigentum der ObsoleteAttribute. Wenn IsError ist true generiert der compiler einen Fehler, und wenn false eine Warnung.
    InformationsquelleAutor tanascius
  3. 5

    Als andere wies darauf hin, Sie können nicht "remove" Methode, aber wenn Sie fühlen, dass es Unrecht zugefügt hat, Sie in irgendeiner Weise können Sie ausblenden in der abgeleiteten Klasse.

    Aus der Dokumentation von Microsoft (jetzt im Ruhestand):

    class Base
{
   public static void F() {}
}
class Derived: Base
{
   new private static void F() {}   //Hides Base.F in Derived only
}
class MoreDerived: Derived
{
   static void G() { F(); }         //Invokes Base.F
}
    • F geschützt werden müssen, ist es nicht?
    • Dieses Beispiel ist direkt aus dem MSDN, also ich nehme an, Sie bedeutete für Sie zu privat sind.
    InformationsquelleAutor R0MANARMY
  4. 1

    Kurze awnser, NICHT alle Klassen Erben von object und object hat diese Methode.

    InformationsquelleAutor BartoszAdamczewski
Schreibe einen Kommentar