Vererbung, Zugriffsebenen, Zugriff bei Klasse und Instanz

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 24 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Im Falle des dritten Beispiels aus Post 15
    Der Erbe ist erstmal ja Me. Me.Test kann ich aber nicht verwenden, weil das wäre ja eine Schleife. MyBase.Test ist also nicht Test o. Me.Test
    Also wenn Me.Test ein Member von B ist, dann denke ich ist MyBase.Test ein weiterer versteckter Member von B, sonst müsste es ja eine versteckte Instanz von A geben, weil A ist ja eigentlich MyBase

    A ist Bauplan von B. Wenn B aber Test per Overrides übergeht und sein eigenes Test schreibt/implementiert, dann ist das so, als ob das MyBase-Test verschwindet und durch B-Test ersetzt wird. Es existiert dann kein MyBase-Test für B. Ok, es existiert schon, hat aber keine Relevanz mehr. Bei Overloads wär es was anderes. Dann würden beide Propertys existieren, aber der Compiler kann eben zwischen beiden unterscheiden. Das wär, als ob zwei Propertys mit unterschiedlichem Namen existieren würden.

    zusammenfassend: MyBase-Test ist ein Teil von B. Es existiert keine geheime MyBase-Instanz innerhalb von B.

    ich lehn mich mal aus dem Fenster und sag mal zusammenfassend für A und B in Code:

    VB.NET-Quellcode

    1. Class A
    2. Overridable Property Foo As Boolean
    3. End Class
    5. Class B : Inherits A
    6. Overrides Property Foo As Boolean
    7. End Class
    wäre inhaltlich so wie

    VB.NET-Quellcode

    1. Class B
    2. Property MyBaseFoo As Boolean
    3. Property Foo As Boolean
    4. End Class

    Und bevor mir hier jetzt jemand kommt mit: »Das ist doch totaler Blödsinn, das kann man doch nicht so zusammenfassen!« Um die Funktionsweise von den beiden Propertys zu erklären: doch. Ansonsten bitte Gegenerklärung bringen!
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    Es ist tatsächliche genau so wie @VaporiZed schreibt. Bei abstract / MustOverride spielt MyBase.Foo keine wirkliche Rolle mehr. Bei virtual / Overridable sieht das schon wieder ganz anders aus.

    Interface -> Strategie, grobe Struktur, Inhaltsdefinition
    Abstrakte Basisklasse -> Standardlogik / Programmspezifischen Verhalten
    Erbe -> Spezifische Logik / Klassenspezifischen Verhalten

    Und spätestens dann wird es relevant ob du this.Test() oder Test() aufrufst.

    Bezogen auf dein Beispiel mit den Properties fällt mir spontan auch mindestens ein Bespiel ein, bei dem das sehr relevant sein kann:

    Abstrakte Basisklasse:

    C#-Quellcode

    1. protected virtual FormLogic.Common.IBase ActiveLogic { get; set; }

    oder

    VB.NET-Quellcode

    1. Protected Overridable ActiveLogic As FormLogic.Common.IBase


    Erbende Klasse:

    C#-Quellcode

    1. private FormLogic.Common.Login<Forms.Common.Login, FormData.Common.Login> _ActiveLogic;
    2. protected override FormLogic.Common.Login<Forms.Common.Login, FormData.Common.Login> ActiveLogic { get { return _ActiveLogic; } }

    oder

    VB.NET-Quellcode

    1. Private _ActiveLogic As FormLogic.Common.Login(Of Forms.Common.Login, FormData.Common.Login)
    2. Protected Overrides ReadOnly Property ActiveLogic As FormLogic.Common.Login(Of Forms.Common.Login, FormData.Common.Login)
    3. Get
    4. Return _ActiveLogic
    5. End Get
    6. End Property


    Das ist ein Beispiel aus einem meiner aktuellen Projekte. An dieser Stelle hat sich beim Vererben auch der Datentyp von ActiveLogic geändert. Denn nicht nur die Klasse in der wir und befinden erbt von einer anderen Klasse auch der Datentyp von ActiveLogic implementiert an dieser Stelle das Interface für FormLogic.

    Anmerkung: Ich habe hier sowohl den VB.NET Code als auch den C#-Code gepostet, weil der TE in VB programmiert und ich in C#. Gerade bei solchen spezifischen Sachen weiß ich dass es Unterschiede in VB.NET und C# gibt, ich kann also nur sicher sagen, dass der Code in C# funktioniert. In VB habe ich das für diesen Kommentar nicht extra getestet, gehe aber davon aus, dass das auch funktioniert :)

    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Yanbel“ ()

    Haudruferzappeltnoch schrieb:

    Das sieht aber nach einem versteckten Member aus. Versteckt weil drauf zugreifen kann man ja nicht mehr wegen des Overrides
    "Versteckter Member" geht in die richtige Richtung - es ist aber noch spezieller - Overridable eben - (ggfs.) Überschrieben.
    Die Property A.Foo ist im Erben B noch da - auch wenn B eine Überschreibung aufweist: B.Foo.
    Dann ist sie aber versteckt, also von aussen kann nur B.Foo zugegriffen werden.
    Aber A.Foo ist dennoch da - ist ja gecodet worden - und allein innerhalb von B, mittels MyBase.Foo kann sie noch angesprochen werden.

    (Und natürlich wird A.Foo nachwievor angesprochen, wenn man garkein B-Objekt instanziert, sondern ein A-Objekt, und dessen Foo-Property aufruft.)

Facebook
Telefonspende