Konstruktoren werden nicht vererbt (Wo laufen sie denn hin ???)

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

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von jvbsl.

    Konstruktoren werden nicht vererbt (Wo laufen sie denn hin ???)

    Hallo zusammen,

    ich habe folgendes festgestellt.

    Wenn eine neue Form über "Projekt / Neues Element hinzufügen / Geerbtes Formular" hinzugefügt wird, dann wird der überladene Konstruktor Sub New(MyBlub as Bla) nicht übernommen.
    Vorhandene Methoden/ Properties - auch überladene - hingegen schon. So wie es eben sein soll.

    Kann man etwas dagegen tun ? Also irgendwo ein Schlüsselwort Sub KeepMe New(MyBlub as Bla) setzen, eine Option in der IDE auswählen, etc. ? Oder bleibt nur, den Konstruktor nochmal neu hinzuschreiben, bzw. nach der Instanzierung die entsprechenden Werte übermitteln ? Wäre ja beides irgendwie nicht besonders elegant..

    Grüße
    Hilfreiche Antworten als solche zu Kennzeichnen wäre klasse 8-)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ftzdOp“ ()

    Wahrscheinlich wäre die richtige Wahl wohl der Einsatz eines Object-Initialisierer, oder ?
    Dim MyObj as New MyClass With {.MyProp = Blub}

    Konstruktoren können eben in VB Net nicht vererbt werden. Punkt
    Hilfreiche Antworten als solche zu Kennzeichnen wäre klasse 8-)

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „ftzdOp“ ()

    Danke Euch beiden für das Feedback !!

    Bluespide schrieb:

    Das Problem ist, wenn du z.B. eine Klasse hast mit 40 Konstruktoren und dann davon erbst, müsstest du alle 40 in der vererbten Klasse neu schreiben und weiterle


    Na, mein Grundgedanke war ja der, dass ich die eben nicht schreiben muss, sondern diese so vererbt werden, wie Methoden & Props. (U.a. C++ und Pascal können das wohl.) Öffnet natürlich LZ-Fehlern eine Tür, aber wäre trotzdem nett. So muss ich halt immer einen neuen Konstruktor schreiben. Bei Formularen ist das halt in der Praxis ein wenig nervig. Aber ich werde das wohl mit einer Init-Methode oder der Objekt-Initialisierung wie oben erwähnt umsetzen. Dieser hat den Nachteil, dass die Prpoerties eben nicht ReadOnly sein können.
    Klassen ohne UI haben wohl eher selten einen entsprechenden Bedarf.

    Guck mal hier: sven-jedeck.visualstudio.com/D…Team/_git/MdiTabbedChilds
    Und hier das Template direkt: Und hier das Template direkt: …vbLlQDQjex3NK5qMlXosrw6DA[/url]
    Da wäre es einfach besser, man hätte den Konstruktor vererbt bekommen können.

    @seh:
    Ich hab mir gewünscht, dass mein Child die Kontruktoren des Parents vererbt bekommen hat.
    Hilfreiche Antworten als solche zu Kennzeichnen wäre klasse 8-)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ftzdOp“ ()

    Eventuell wäre sowas angebracht:

    VB.NET-Quellcode

    1. Class B
    2. Public ReadOnly Property Foo As Integer
    3. '...
    4. Public Sub New(BParameters As BParameters)
    5. Foo = BParameters.Foo
    6. End Sub
    7. End Class
    8. Class C
    9. Inherits B
    10. Public Sub New(BParameters As BParameters)
    11. MyBase.New(BParameters)
    12. End Sub
    13. End Class
    14. Class D
    15. Inherits C
    16. Public ReadOnly Property Bar As Double
    17. '...
    18. Public Sub New(BParameters As BParameters, DParameters As DParameters)
    19. MyBase.New(BParameters)
    20. Bar = DParameters.Bar
    21. End Sub
    22. End Class
    23. Class BParameters
    24. Public ReadOnly Property Foo As Integer
    25. '...
    26. Public Sub New(NewFoo As Integer)
    27. Foo = NewFoo
    28. End Sub
    29. End Class
    30. Class DParameters
    31. Public ReadOnly Property Bar As Double
    32. '...
    33. Public Sub New(NewBar As Double)
    34. Bar = NewBar
    35. End Sub
    36. End Class
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    ftzdOp schrieb:

    Geerbtes Formular" hinzugefügt wird, dann wird der überladene Konstruktor Sub New(MyBlub as Bla) nicht übernommen.


    ftzdOp schrieb:

    Oder bleibt nur, den Konstruktor nochmal neu hinzuschreiben
    Ja, ist so.
    Mach dir klar, was BaseClass.Sub.New() macht: es erzeugt ein neues BaseClass-Objekt.
    natürlich kannste das nicht an DerivedClass vererben, denn BaseClass.Sub.New erzeugt nunmal ein BaseClass-Objekt und kein DerivedClass-Objekt.

    So tickt jdfs bislang die Sprache, kann sein, dass man das zumindest theoretisch ändern könnte, aber ich glaub nicht, dass das je passiert, selbst wenn es technisch möglich wäre.
    Auch hier Danke !!

    ErfinderDesRades schrieb:

    Mach dir klar, was BaseClass.Sub.New() macht: es erzeugt ein neues BaseClass-Objekt.
    natürlich kannste das nicht an DerivedClass vererben, denn BaseClass.Sub.New erzeugt nunmal ein BaseClass-Objekt und kein DerivedClass-Objekt.


    OK, jetzt habe ich nicht nur die Tatsache, sondern auch das warum. Gut :thumbup: Danke.

    @Nico: Da steig ich nicht dahinter. Schaue ich mir nochmal in Ruhe an.
    Hilfreiche Antworten als solche zu Kennzeichnen wäre klasse 8-)
    Mir wäre nicht bekannt, dass c++ das kann, denn dann würde der ganze initializer code fehlen(es sei denn der kompiler erstellt diesen wie bei leeren Konstruktoren).
    Falls du wirklich so viele Konstruktoren brauchst, was ich nicht glaube, kannst du dir evtl ein t4 template erstellen und damit ein paar Dinge vereinfachen. Sinnvoller ist wohl eher deine Konstruktoren zu andern.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Mir ging es nur um das Verständnis. Danke aber.

    Im Netz war bei der Suche zum Thema immer wieder zu lesen, C++ könne dies. Deshalb aber auch die vorsichtige Fomulierung mit "..können das wohl."

    Beste Grüße and alle Antworter !
    Hilfreiche Antworten als solche zu Kennzeichnen wäre klasse 8-)
    Ah C++ kann da tatsächlich etwas, aber du musst trotzdem hingehen und angeben, dass der Konstruktor übernommen werden soll und zwar in der subclass, also statt:

    Quellcode

    1. subclass(int i):baseclass(i){}

    halt eben

    Quellcode

    1. using baseclass::baseclass;

    so sonderlich krass ist das auch nicht, könnte aber sein, dass er sich dann alle konstruktoren schnappt...aber ansonsten musst du in VB dasselbe machen und ist auch nicht die Welt...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---