C# Benennung gecasteter Eigenschaft

[Horst S. (Gast)]

 //the base class
    abstract class BaseClass
    {
        //Constr.
        public BaseClass(BaseClassSettings settings)
        {
            Settings = settings;
        }

        //Settings prop
        public BaseClassSettings Settings { get; set; }


        //Example to access settings
        private bool GetSettingSample()
        {
            return Settings.Enabled;   
        }
    }


    //the base class settings type
    abstract class BaseClassSettings
    {
        public bool Enabled { get; set; }
    }


    // the implementation
    class DerivedClass : BaseClass
    {
        //Constr.
        public DerivedClass(DerivedClassSettings settings) : base(settings) { }


        // Variante1: name casted setting as member
        private DerivedClassSettings settings{get{return (DerivedClassSettings) Settings; }}
        
        // Variante2: special sign casted type with underline
        private DerivedClassSettings _Settings { get { return (DerivedClassSettings)Settings; } }


        //Examples to access settings
        private bool GetSettingSample1()
        {
            return settings.Enabled && settings.Visible;
        }

        private bool GetSettingSample2()
        {
            return _Settings.Enabled && _Settings.Visible;
        }

    }

    //derived settings type
    class DerivedClassSettings : BaseClassSettings
    {
        public bool Visible { get; set; }    
    }

Wenn ich, wie oben gezeigt...
a) Die Eigenschaft "Settings" sowohl in der abstrakten Basisklasse, als 
auch in der Ableitung verwenden möchte.
b) In Abhängigkeit vom Ableitungstyp auch unterschiedliche 
Eigenschaftentypen (als Ableitung vom Eigenschaftentyp der Basisklasse) 
verwenden möchte.
...muss ich ja in der Ableitung irgendwie casten.

Wie benenne ich denn die Cast-Property?
Wie eine MemberVariable (Variante1) oder zeichne ich die speziell aus 
(z.B. durch Unterstrich, wie in Variante2)?

oder macht Ihr das ganz anders?

[Dr. Sommer (Gast)]

Warum ist denn die "Settings" Eigenschaft der Basisklasse "public", aber 
in der abgeleiteten Klasse "private"? Soll das so?
Falls nicht (und beide Eigenschaften protected oder public sein können), 
würde ich die Eigenschaft in der abgeleiteten Klasse genau gleich nennen 
wie in der Basisklasse, und sie somit überschreiben (dazu ist scheinbar 
noch das Keyword "new" oder "virtual" nötig). So verwendet man 
automatisch immer das richtige...

[Michael (Gast)]

ich bin mir zwar nicht sicher, ob ich verstehe worauf du hinaus willst, 
aber versuchs mal damit:

class DerivedClass : BaseClass
{
    //Constr.
    public DerivedClass(DerivedClassSettings settings) : base(settings)
    {
        Settings = settings;
    }

    // Variante1: name casted setting as member
    private new DerivedClassSettings Settings;

    //Examples to access settings
    private bool GetSettingSample1()
    {
        return Settings.Enabled && Settings.Visible;
    }
}

[Horst S. (Gast)]

Mit virtual geht's nicht. Da muss die Funktionssignatur (in diesem Fall 
der Eigenschaftentyp) identisch sein.

Ha, mit new geht's, sogar mit Interface:

    interface ILoadableObject
    {
        BaseClassSettings Settings{get;}
    }

    
    //the base class
    abstract class BaseClass
    {
        //Constr.
        public BaseClass(BaseClassSettings settings)
        {
            Settings = settings;
        }

        //Settings prop
        public BaseClassSettings Settings { get; private set; }


        //Example to access settings
        public bool GetSettingSample()
        {
            return Settings.Enabled;
        }
    }


    //the base class settings type
    abstract class BaseClassSettings 
    {
        public bool Enabled { get; set; }
    }


    // the implementation
    class DerivedClass : BaseClass, ILoadableObject
    {
        //Constr.
        public DerivedClass(DerivedClassSettings settings) : base(settings) { }


        // !!! Hiding Access to base class Setting prop
        public new DerivedClassSettings Settings 
        { 
            get { return (DerivedClassSettings)base.Settings; }
        }

        
        //Example to access settings
        public bool GetSettingSampleDerived()
        {
            return Settings.Enabled && Settings.Visible;
        }
    }

    //derived settings type
    class DerivedClassSettings : BaseClassSettings
    {
        public DerivedClassSettings(bool visible, bool enabled)
        {
            Visible = visible;
            Enabled = enabled;
        }
        public bool Visible { get; set; }
    }

jo, das klappt, danke.


P.S. Michael. Deine Variante würde die Settings nicht an die Basisklasse 
weiterreichen, sondern als Variable in der Ableitung spiegeln?!?

[Michael (Gast)]

Horst S. schrieb:
> P.S. Michael. Deine Variante würde die Settings nicht an die Basisklasse
> weiterreichen, sondern als Variable in der Ableitung spiegeln?!?

Der Konstruktor der abgeleiteten Klasse ruft den Konstruktor der 
Basisklasse auf und gibt die Settings als Parameter weiter. Somit hat 
die Basisklasse eine Referenz auf die Settings vom Typ BaseClassSettings 
erhalten.

Hab es jetzt nicht getestet, aber sollte funktionieren

[Borislav B. (boris_b)]

Das klingt irgendwie ziemlich vermurkst ;-)

Wäre es nicht deutlich einfacher zwei verschiedene Eigenschaften zu 
verwenden oder ein Interface zu benutzen?

[Horst S. (Gast)]

Michael schrieb:
> Der Konstruktor der abgeleiteten Klasse ruft den Konstruktor der
> Basisklasse auf und gibt die Settings als Parameter weiter. Somit hat
> die Basisklasse eine Referenz auf die Settings vom Typ BaseClassSettings
> erhalten.
>
> Hab es jetzt nicht getestet, aber sollte funktionieren

Doch, Du hast recht. Einzig unschön bei Deiner Lösung: Du hast zwei 
getrennte Referenzen. Da darf ich dann nie-nie-niemals dem dunklen 
Gedanken verfallen, eben mal den Settings 'nen Setter zu verpassen.

[Michael (Gast)]

Horst S. schrieb:
> Doch, Du hast recht. Einzig unschön bei Deiner Lösung: Du hast zwei
> getrennte Referenzen. Da darf ich dann nie-nie-niemals dem dunklen
> Gedanken verfallen, eben mal den Settings 'nen Setter zu verpassen.

auch das kannst du machen, nur muss der Setter die Referenz der 
abgeleiteten Klasse und die Referenz der Basisklasse ändern.
Aus solchen Gründen verwendet man ja Setter. Damit kann man das Ändern 
der Referenzen oder Variablen kontrollieren.

public DerivedClassSettings Settings
{
    set
    {
        this.settings = value;
        base.settings = value;
    }
}

beachte, dass die beiden Referenzen settings nun klein geschrieben sind 
(wie man das bei private Variablen und Referenzen so macht), damit 
Setter den gleichen Namen, nur groß geschrieben haben darf.

[Horst S. (Gast)]

Dann kann ich's allerdings auch gleich, wie oben, als Verweis auf die 
Basisreferenz mit Casting betreiben.

        public new DerivedClassSettings Settings 
        { 
            get { return (DerivedClassSettings)base.Settings; }
            set { base.Settings = value;}
        }

[tk (Gast)]

Für mich sieht das auch reichlich undurchsichtig aus.

Kann mir mal jemand der C# Pros die Objektlayouts mitsamt statischen und 
dynamischen Typen der Variablen/Referenzen zur Laufzeit der Properties 
grob auflisten?
Mich würde die Semantik dahinter und v.a. hinter 'new' interessieren.

In Hoffnung einer Erleuchtung: Danke schon mal.

[Horst S. (Gast)]

tk schrieb:
> Für mich sieht das auch reichlich undurchsichtig aus.
>
> Kann mir mal jemand der C# Pros die Objektlayouts mitsamt statischen und
> dynamischen Typen der Variablen/Referenzen zur Laufzeit der Properties
> grob auflisten?
> Mich würde die Semantik dahinter und v.a. hinter 'new' interessieren.
>
> In Hoffnung einer Erleuchtung: Danke schon mal.

Funktional ist mir das klar. Bei "virtual" testet der Compiler die 
Signatur (also Name, Parameter- und Rückgabetypen) der Funktionen in 
Basis und Ableitung auf Übereinstimmung. Bei "new" werden gleichnamige 
Funktionen mit unterschiedlichen Signaturen durchgelassen (Soweit ich 
weiß, ist dann aber die Funktion aus der Basis dann von außen gesehen 
endgültig wech, das ist also keine Überladung).


Ob das Schick ist? Ehrliche Antwort? Ich wusste, dass es das 
"new"-Schlüsselwort für Funktionen gibt, gebraucht hab ich's in 10 
Jahren nicht.
Hier scheint's mal 'nen pragmatischen Ansatz zu bieten, Nicht nur aus 
reiner Schreibfaulheit, weil ich keinen Bock habe, in jeder zweiten 
Zeile meiner Ableitung die Settings zu casten, sondern auch, weil ich 
jetzt wirklich nur die passenden Settings zur Ableitung von außen in das 
Objekt stopfen kann.

Ob ich mir allerdings in zwei Jahren aus meinem Code noch klar machen 
kann, dass ich durch den Gebrauch des new-Schlüsselwörtchens an dieser 
Stelle diese doppeltgeführte Objekthierarchie ("Derived" erbt von "Base" 
UND "DerivedSettings" erbt von "BaseSettings") implementiert habe, 
naja...

...das gehört wahrscheinlich in den Summaries dokumentiert (aber wer 
liest die schon!).

[Markus (Gast)]

Für den Fall, dass DerivedClassSettings von BaseClassSettings ableitet 
(ableiten kann), gibt es noch eine elegante Möglichkeit, die ohne 
fehleranfälligen Cast auskommt und die die Typprüfung bereits zur 
Compile-Zeit durchführt:

using System;

public class BaseClassSettings
{
    public bool Enabled { get; set; }
}

public class DerivedClassSettings
    : BaseClassSettings
{
    public int Value { get; set; }
}

public abstract class BaseClass<TSettings>
    where TSettings : BaseClassSettings
{
    public BaseClass()
    {
    }

    public TSettings Settings { get; set; }

    private bool GetSettingSample()
    {
        return Settings.Enabled;
    }
}

public class DerivedClass
    : BaseClass<DerivedClassSettings>
{
    private void SettingsTest()
    {
        Console.WriteLine("BaseClassSetting.Enabled: {0}", Settings.Enabled);
        Console.WriteLine("DerivedClassSetting.Value: {0}", Settings.Value);
    }
}

Grüße
Markus

[Horst S. (Gast)]

Lol, 'nen Constraint auf'm Generic, da bin ich noch gar nicht drauf 
gekommen!

Und natürlich muss DerivedClassSettings von BaseClassSettings erben, 
weil ansonsten in BaseClass nix mit den Settings anzustellen wäre.

Mindestens genauso unverständlich für 'nen Youngster zu lesen, wie die 
Sache mit dem "new"-Schlüsselwort, aber guter Plan! (Vielleicht sogar 
besser wiederzufinden!!!)