[VB.net] OO - In parent weten welke child ge-init wordt

[Armageddon_2k]

Okay titel is misschien wat wazig, maar het gaat om vb.net waarin ik een aantal classes heb met overerving.
Het zijn dataconnector variabelen die op een specifiek platform moeten gaan werken.

Ik heb een parent class
[myVariable]
met child classes.
[myVarInteger] [myVarString] [myVarReal]

ze heten bij mij iets anders, maar dit lijkt me het duidelijkst voor jullie.

De class myVariable, verzorgt de new()

Maar is het nu ook mogelijk om in de myVariable te weten welke childclass er gebruikt is?
Dus stel ik doe:
[myVarString].new()

Dan wordt uiteraard de new van [myVariable] aangeroepen, maar kan ik hier ook achterkomen in de new() functie zelf?

[RobIII]

Me.GetType()

/Edit:

Visual Basic .NET:

Module Armageddon_2k

    Sub Main()
        Dim x = New MyInteger()
        Dim y = New MyString()

        Console.ReadLine()
    End Sub

End Module

MustInherit Class MyVariable
    Public Sub New()
        Console.WriteLine(Me.GetType().Name)
    End Sub
End Class

Class MyInteger
    Inherits MyVariable
End Class

Class MyString
    Inherits MyVariable
End Class

MyInteger
MyString

[ Voor 96% gewijzigd door RobIII op 13-07-2011 15:08 ]

[Armageddon_2k]

Thanks, had al even een testje gemaakt.
Wat stom zeg, ik was er heilig van overtuigd dat ik daarmee de parent zou terug krijgen.

[RobIII]

Armageddon_2k schreef op woensdag 13 juli 2011 @ 15:05:

Thanks, had al even een testje gemaakt.
Wat stom zeg, ik was er heilig van overtuigd dat ik daarmee de parent zou terug krijgen.

Doe me een lol en doe dat voortaan eerst. Zitten we onze tijd niet voor niets te verdoen

[Armageddon_2k]

RobIII schreef op woensdag 13 juli 2011 @ 15:07:
[...]
Doe me een lol en doe dat voortaan eerst. Zitten we onze tijd niet voor niets te verdoen

Nee ik had een voorbeeld test gemaakt toen jij met GetType() kwam, dus je hebt jij tijd niet lopen verdoen.
Dus zonder je hulp was ik nog aan het dobberen geweest

[ Voor 9% gewijzigd door Armageddon_2k op 13-07-2011 15:08 ]

[Bu588]

Je moet je wel afvragen of het een goed idee is dat een parent weet door welke childclass hij wordt aangeroepen. Normaalgesproken wil je toch voorkomen dat dit gebeurt omdat je dan logica in de parent zou opnemen die specifiek voor childs is (en dus in de child zou moeten staan)?

[Armageddon_2k]

Bu588 schreef op woensdag 13 juli 2011 @ 15:15:
Je moet je wel afvragen of het een goed idee is dat een parent weet door welke childclass hij wordt aangeroepen. Normaalgesproken wil je toch voorkomen dat dit gebeurt omdat je dan logica in de parent zou opnemen die specifiek voor childs is (en dus in de child zou moeten staan)?

Dr zitten een aantal functies in die door de parent worden uitgevoerd waaronder een Initializer() functie.
Deze worden uitgevoerd met child specifieke eigenschappen. (bijvoorbeeld message bitsize).
Als er wat misgaat in de Initializer, vindt ik het wel prettig om te weten om welke childclass het gaat.

[Bu588]

In dat geval zou ik de child-specifieke eigenschappen laten doen door een functie in de child. Door die als een abstracte functie te definieren in de parent, dwing je jezelf om elke child te voorzien van deze functie. De returncode van deze functie kun je gebruiken om te controleren of hij succesvol werd uitgevoerd, zo niet dan kun je in de parent een exception genereren waarin je met de getType() functie de naam van de echte class opneemt. Dit voorkomt dat je bij toevoegen van een nieuwe child ook de parent moet aanpassen, wat volgens mij een van de doelen is van OO-programmeren (toch?).

[Armageddon_2k]

Bu588 schreef op woensdag 13 juli 2011 @ 15:23:
In dat geval zou ik de child-specifieke eigenschappen laten doen door een functie in de child. Door die als een abstracte functie te definieren in de parent, dwing je jezelf om elke child te voorzien van deze functie. De returncode van deze functie kun je gebruiken om te controleren of hij succesvol werd uitgevoerd, zo niet dan kun je in de parent een exception genereren waarin je met de getType() functie de naam van de echte class opneemt. Dit voorkomt dat je bij toevoegen van een nieuwe child ook de parent moet aanpassen, wat volgens mij een van de doelen is van OO-programmeren (toch?).

In sommige gevallen ben ik dat met je eens, maar de Initializer functie is in elk opzicht hetzelfde op een aantal parameters na. Je zou dan een 10 regels code in al je child classes terug zien komen. Met als enige verschil een paar MessageSizes. Vind ik nou niet echt fraai.

En ik kan trouwens Chilclasses toevoegen wat ik wil, ik hoef mn parent niet aan te passen. Maargoed dat is een leuke discussie als jij niet weet hoe de code er uitziet en waar het voor gebruikt wordt.

[ Voor 9% gewijzigd door Armageddon_2k op 13-07-2011 15:29 ]

[Big Womly]

Armageddon_2k schreef op woensdag 13 juli 2011 @ 15:26:
[...]


In sommige gevallen ben ik dat met je eens, maar de Initializer functie is in elk opzicht hetzelfde op een aantal parameters na. Je zou dan een 10 regels code in al je child classes terug zien komen. Met als enige verschil een paar MessageSizes. Vind ik nou niet echt fraai.

En ik kan trouwens Chilclasses toevoegen wat ik wil, ik hoef mn parent niet aan te passen. Maargoed dat is een leuke discussie als jij niet weet hoe de code er uitziet en waar het voor gebruikt wordt.

Maar nog altijd fraaier dan dat je parent class die gaat uitvoeren voor je child classes.
Wat eigen is aan de child class moet in de child class blijven, en daarmee basta!

schrijf die gemeenschappelijke regels code in je parent class en die specifieke regels in je child class en laat dan je child functie de parent functie oproepen.

Is het geheime code, of kan je die met ons delen? Want ik kan mij echt geen situatie inbeelden waarbij je moet weten wat voor type je child is zonder dat je dat moet aanpassen als je nieuwe child classes definieerd.

[ Voor 10% gewijzigd door Big Womly op 13-07-2011 15:34 ]

[Armageddon_2k]

Again, alle code in de parent is hetzelfde alleen puur de parametes zijn verschillend.

Maargoed ik ga kappen met discussie, ik heb hier een deel van de code neer gezet specifiek voor het "probleem" waar ik een oplossing voor zocht. Als je over het hele ontwerp commentaar wilt leveren, jammer dan want je weet niet hoe het ontwerp in z'n totaliteit inelkaar staat.

[Big Womly]

Ok, got your point

maar denk toch even na over deze situatie:

code:

Abstract Class Parent
  Function fp()
    'Die 10 regels code
    HandleChildSpecific()
  End Function
  
  Abstract Function HandleChildSpecific()
End Class

Class Child
  Function HandleChildSpecific()
    'Hier je child specifieke code
  End Function
End class

[NickThissen]

Big Womly schreef op woensdag 13 juli 2011 @ 15:44:
Ok, got your point

maar denk toch even na over deze situatie:

Als ik het goed heb moet je nu wel uitkijken dat je je 'fp' functie niet in de constructor van Parent gaat aanroepen, omdat je dan een virtual (nou ja, abstracte) method in je constructor aanroept. Ok, niet direct maar wel indirect, ik weet niet of het dan nog steeds een probleem is? Het probleem normaal namelijk is dat de constructor van je Child nog niet gedaan is, de virtual method wordt dus uitgevoerd in Child voordat de constructor van Child uitegvoerd is; als de implementatie van die virtual method dus afhangt van iets wat in de constructor van Child geinitializeerd wordt gaat het mis.

Verder heet een abstract class in VB 'MustInherit' en een abstract method 'MustOverride', maar goed, wie onthoudt dat


Verder ben ik het wel eens; het is absoluut niet goed om child-specifieke zaken in je parent te gaan regelen. Als die initializatie code vrijwel hetzelfde is en je die niet wilt kopieren dan zet je dus alle code die inderdaad hetzelfde is in de parent, en alle delen die specifiek zijn per child in je childs. Dat is nou net het nut van inheritance, beetje vreemd om dat te negeren

[Grijze Vos]

Armageddon_2k schreef op woensdag 13 juli 2011 @ 15:35:
Als je over het hele ontwerp commentaar wilt leveren, jammer dan want je weet niet hoe het ontwerp in z'n totaliteit inelkaar staat.

Sommige mensen hebben niet meer nodig dan 15 regels code om een antipattern te herkennen...

[Herko_ter_Horst]

Aangezien je dacht dat je in de GetType() de parent terug zou krijgen, heb ik het gevoel dat je niet snapt hoe polymorfisme werkt bij overerving. Je antipattern van kennis van subclasses in de parent kan hier mogelijk ook mee worden opgelost: de Initializer die nu kind-specifieke code aanroept, kan worden vervangen door een Initializer in de parent die parent specifieke dingen doet en een override van die Initializer in elk child die de parent Initializer aanroept en daarna z'n eigen ding doet.

Dat of een Initializer die een template method aanroept die je in elk child implementeert.

[Janoz]

Armageddon_2k schreef op woensdag 13 juli 2011 @ 15:26:
[...]


In sommige gevallen ben ik dat met je eens, maar de Initializer functie is in elk opzicht hetzelfde op een aantal parameters na. Je zou dan een 10 regels code in al je child classes terug zien komen. Met als enige verschil een paar MessageSizes. Vind ik nou niet echt fraai.

Het hele idee dat een parent daadwerkelijk wat van de implementaite van zijn child moet weten is gewoon brak. Dat klopt niet. Dat jij geen fatsoenlijke oplossing denkt te kunnen verzinnen betekent niet dat die er niet is.

Je hoeft bijvoorbeeld niet de hele initializer functie abstract te maken. Je kunt ook een abstracte getMessageSizeX methode maken.

[.oisyn]

Of die gegevens meegeven in de ctor van de base class.

Ik ben het eens met de opmerking over het oppassen met aanroepen van een derived method vanuit de base constructor, da's vragen om moeilijkheden. In "sommige" talen kan dat niet eens

[ Voor 64% gewijzigd door .oisyn op 13-07-2011 17:03 ]

[Janoz]

Daarom heb ik het ook expliciet over een abstracte method. Maar het meegeven aan de constructor is onderdaad een nog nettere oplossing.

[apokalypse]

Armageddon_2k schreef op woensdag 13 juli 2011 @ 15:35:
Maargoed ik ga kappen met discussie, ik heb hier een deel van de code neer gezet specifiek voor het "probleem" waar ik een oplossing voor zocht. Als je over het hele ontwerp commentaar wilt leveren, jammer dan want je weet niet hoe het ontwerp in z'n totaliteit inelkaar staat.

Wel hulp willen, terwijl het heel basic materie is, maar een goede kritische vraag wordt afgedankt. Beetje jammer.

[ Voor 3% gewijzigd door apokalypse op 13-07-2011 17:14 ]

[Niemand_Anders]

Ik denk dat het ook verstandig is, dat je een keer het Open/Closed Principe leest.

[.oisyn]

Janoz schreef op woensdag 13 juli 2011 @ 17:10:
Daarom heb ik het ook expliciet over een abstracte method.

Ik heb het erover dat het potentieel gevaarlijk is om een (al dan niet abstracte) method aan te roepen vanuit de base ctor die in de derived class overridden is, omdat de ctor van de derived dan nog niet is aangeroepen. De method abstract maken verandert daar niets aan

[Janoz]

Tjongejonge, ik ben niet scherp .. Ik zat met mijn hoofd in die apparte (niet constructor) initialize functie en was even vergeten dat die al vanuit de constructor aangeroepen zou worden. Ik dacht dat je opmerking meer sloeg op het "design for extention".

[Armageddon_2k]

Janoz schreef op woensdag 13 juli 2011 @ 17:00:
[...]
Je hoeft bijvoorbeeld niet de hele initializer functie abstract te maken. Je kunt ook een abstracte getMessageSizeX methode maken.

Nou toch maar even op de discussie inspringen.
Wat jij hier zegt, is precies hoe ik het inelkaar heb steken.
Goed, ik pleur het hier neer.

Parent

Visual Basic .NET:

    Friend MustOverride Sub GetAdsStreamLength()

    '*****Constructor()*****
    'Creates a new instance of the object
    Public Sub New(ByRef Client As TwinCatConnection, ByVal TagName As String, Optional ByVal Cycletime As Long = 200, Optional ByVal Adstransmode As AdsTransMode = AdsTransMode.OnChange)

        TagName = TagName
        TcAdsClient = Client.TcClient
        AdsStreamLength = GetAdsStreamLength()
        AdsStream = New AdsStream(AdsStreamLength)

        InitializeComponent(Cycletime, Adstransmode)
    End Sub

    '*****InitializeComponent()*****
    'Initilizes the component
    Private Sub InitializeComponent(ByVal Cycletime As Long, ByVal Adstransmode As AdsTransMode)
        Dim DataStream As New AdsStream(AdsStreamLength)  'DataStream for reading current value

        Try
            If TcAdsClient.IsAlive Then

                'Add notification handle for datachange events (handled in TwinCatRuntime)
                DeviceNotification = TcAdsClient.AddDeviceNotification(TagName, AdsStream, Adstransmode, CInt(Cycletime), 0, Me)

                'Get variable handle for manual read/write actions
                VariableHandle = TcAdsClient.CreateVariableHandle(TagName)

                'Read current value (executed by child of TwinCatVariable)
                TcAdsClient.Read(VariableHandle, DataStream)
                AdsStreamReadValue(DataStream)

                id = AddTagEntry(TagName)
            End If

        Catch ex As AdsErrorException

            Dim exception As AdsErrorException = ex

                If MessageBox.Show(("Connecting to variable <" & TagName & ">" & vbCrLf & _
                                 exception.Message), "Class xxxxx", MessageBoxButtons.OKCancel, _
                                 MessageBoxIcon.Exclamation, MessageBoxDefaultButton.Button1) = DialogResult.Cancel Then

            End If

        End Try

        DataStream = Nothing
    End Sub

De Child implementeert de "GetAdsStreamLength".

En de enige reden waarom ik dus wil weten welke child ik mee bezig ben, is voor de error message.
De TcAdsClient is "Semi-gedocumenteerd" en doet dus soms spontaan dingen die ik niet wil.
En het is dan makkelijk om te weten of zich dit bij alle variabelen (String/Bool/Int) voordoet, of alleen voor een specifieke.

[Armageddon_2k]

apokalypse schreef op woensdag 13 juli 2011 @ 17:13:
[...]
Wel hulp willen, terwijl het heel basic materie is, maar een goede kritische vraag wordt afgedankt. Beetje jammer.

Beetje jammer dat mensen altijd bij voorbaat al hebben bedacht wat iemand fout doet, prima als je commentaar gaat geven als ik de hele code neer gooi. En als je commentaar hebt op de code die ik net post, prima, geen moeite mee.

Maar als iemend voor zichzelf gaat bedenken wat ik wil gaan doen met die GetType() functie, en daardoor maar besluit dat het hele ontwerp scheef is, dat vind ik een beetje jammer.

[.oisyn]

Even voor de duidelijkheid, je wilt dus op de plek van "Class xxxxx" op regel 41 de naam van de concrete klasse hebben?

[Janoz]

En iets als Me.GetType() werkt niet omdat?

[Armageddon_2k]

Even voor de duidelijkheid, je wilt dus op de plek van "Class xxxxx" op regel 41 de naam van de concrete klasse hebben?

Yup

Janoz schreef op donderdag 14 juli 2011 @ 11:17:
En iets als Me.GetType() werkt niet omdat?

Dat werkt prima, maar ik kon er niet opkomen
Dit was de code "Voor" de aanpassing met Me.GetType.

[ Voor 34% gewijzigd door Armageddon_2k op 14-07-2011 11:29 ]