[.net, C#] Set/Get von Properties vererben

[Seraph]

Ich habe ein eigentlich recht triviales Problem, finde dennoch keine Loesung die mir gefaellt. Mir geht es darum, dass ich Teile einer Property einer Klasse in einer abgeleiteten Klasse ueberschreiben moechte, z.B. den Setter, da der in theoretisch in jeder abgeleiteten Klasse verschieden sein kann. Mal ein wenig Beispielcode, welcher es hoffentlich verstaendlicher macht.

Code: Alles auswählen

class Base
{
    protected int m_test;

    public int Test
    {
        get { return m_test; }
    }

}

class Special : Base
{
    public int Test
    {
        set { /* do something */ }
    }
}

Also in der Basis-Klasse moechte ich, dass mir der Get-Accessor bereit gestellt wird, da er immer gleich bleiben wird. In der abgeleiteten Klasse moechte ich noch den Set-Accessor hinzufuegen. Ich habe in der Doku leider nichts gefunden, was mir damit wirklich helfen wuerde. Vielleicht ist es auch gar nicht moeglich, ausser man verwendet wieder zwei normale Methoden. Hat jemand irgendwelche Ideen oder Vorschlaege?

[Dirk Schulz]

hi,

keine Ahnung, ob ichs richtig verstanden habe, kenne mich mit C# auch nicht aus, aber ist das nicht dasselbe wie hier:

http://msdn.microsoft.com/de-de/library ... 80%29.aspx

Vielleicht muss man die Property in der Basisklasse nicht unbedingt abstrakt definieren, kenn mich da nicht aus.

Mir gehts hauptsächlich um das "override"-Attribut, damit schonmal probiert?

frittentuete

[dowhilefor]

Das geht ohne weiteres mit virtual vor dem Property in der Basisklasse und override vor dem Property in der abgeleiteten Klasse.
Du kannst dann in der abgeleiteten Klasse einfach nur den Setter Schreiben.

[Seraph]

Erstmal danke fuer die Antworten. Der Link hilft mir leider nicht weiter, weil er keinen Set-Accessor hinzufuegt.

@Nico: Nein, es geht nicht. Der Fehler ist dann, dass er keinen zu ueberschreibenden Set-Accessor finden kann, was auch durchaus Sinn macht. Ich kann das natuerlich umgehen, indem ich einen leeren Set-Accessor in die Basisklasse schreiben, aber das widerspricht imho ein wenig dem Sinn dahinter, zumal es dann standardmaessig keine Read-Only-Properties mehr waeren.

Im Moment habe ich es mit dem new-Keyword geloest und dass der get-Accessor den entsprechenden get-Accessor der Basisklasse aufruft. Ueber eine andere Moeglichkeit wuerde ich mich dennoch freuen, weil es jetzt irgendwie so ein wenig doppelt gemoppelt ist und die urspruengliche Intention verloren geht.

[NeoInferno]

Wie wäre es, im Property-Getter/Setter lediglich virtuelle Funktionen aufzurufen, die du in den Unterklassen überschreiben kannst:

Code: Alles auswählen

class Base
{
private int test;

public int Test
{
get { return OnGetTest(); }
set { OnSetTest(value); }
}

protected virtual int OnGetTest()
{
return test;
}
protected virtual void OnSetTest(int value)
{
test = value;
}

}

[Seraph]

Dieses mache ich erst beim naechsten Schritt, weil es vom Design her da passt, beim ersten Schritt aber leider noch nicht. :(

[dowhilefor]

Was spricht dagegen? Weil sonst ist mir das problem nicht so ganz klar.

Code: Alles auswählen

    abstract class Base
    {
        virtual public int Number
        {
            get { return iNumber; }
            set {}
        }

        protected int iNumber;
    }

    class Child : Base
    {
        override public int Number
        {
            set { iNumber = value; System.Console.WriteLine("overriden"); }
        }
    }

Oder möchtest du vermeiden das manche Abgeleiteten Klassen einen Setter bekommen? Ansonsten fällt mir wirklich nur new ein.

[Seraph]

Oder möchtest du vermeiden das manche Abgeleiteten Klassen einen Setter bekommen?

Genau. :)

[LaBerg]

Hi!

Also das was du vor hast geht so nicht. Man kann den gettern und settern zwar unterschiedlichen Zugriffsschutz durch public, protected und private geben, aber man kann sie nicht getrennt mit override oder new behandeln.
Wie sinnvoll das ist eine Readonly Property auf einmal schreibbar zu machen, ist sicher auch fraglich. Ich persönlich würde in diesem Fall wohl der Basisklassse einen setter spendieren und dort "throw new NotSupportedException();" reinschreiben oder eben die Standardimplementierung "m_iTest = value;"

Alternativ wäre sowas möglich:

Code: Alles auswählen

class BaseReadClass
    {
        protected int m_iTest;
        public virtual int Test
        {
            get { return m_iTest; }
            
        }
    }

    class BaseReadWriteClass : BaseReadClass
    {
        public new virtual int Test
        {
            get { return base.Test; }
            set { m_iTest = value; }
        }
    }

    class Inher2Class : BaseReadWriteClass
    {
        public override int Test
        {
            set
            {
                base.Test = 4711;
            }
        }
    }

Alles was auf die Property schreiben können soll, leitet dann eben von "BaseReadWriteClass" alles andere eben von "BaseReadClass".

[Seraph]

Dein Code spiegelt meine jetzige Loesung wieder.

Wie sinnvoll das ist eine Readonly Property auf einmal schreibbar zu machen, ist sicher auch fraglich.

Was spricht dagegen, dass eine Property in verschiedenen vererbten Klassen verschieden gehandhabt wird, sprich in einigen kann sie nur gelesen werden, in anderen kann sie sogar geaendert werden? Und ich persoenlich finde es besser, wenn man es schon zur Compile-Zeit weiss, was moeglich ist und was nicht.

[SPech]

DIe einizige Möglichkeit die mir dazu einfallen würde wäre eine weitere Ebene einzuziehen und dort den Setter zu setzen mit finally/sealed.

[Alexander Kornrumpf]

Dein Code spiegelt meine jetzige Loesung wieder.

Wie sinnvoll das ist eine Readonly Property auf einmal schreibbar zu machen, ist sicher auch fraglich.

Was spricht dagegen, dass eine Property in verschiedenen vererbten Klassen verschieden gehandhabt wird, sprich in einigen kann sie nur gelesen werden, in anderen kann sie sogar geaendert werden? Und ich persoenlich finde es besser, wenn man es schon zur Compile-Zeit weiss, was moeglich ist und was nicht.

Ein Wunsch, der in Meinen Augen einen wesentlichen Philosophieunterschied zwischen C++ und C# aufzeigt.

[Seraph]

Ein Wunsch, der in Meinen Augen einen wesentlichen Philosophieunterschied zwischen C++ und C# aufzeigt.

Das dachte ich mir auch schon, dass es daran liegen koennte.

[LaBerg]

Ein Wunsch, der in Meinen Augen einen wesentlichen Philosophieunterschied zwischen C++ und C# aufzeigt.

Das dachte ich mir auch schon, dass es daran liegen koennte.

Ich denke man kann beides mit dem Konzept der Verbung rechtfertigen mit dem Konzept der Verbung. Wenn davon ausgeht, dass eine abgeleitete Klasse eine Bedingung immer nur verstärken darf und niemals abschwächen. Das ist ein sehr wichtiger Grundstatz der Vererbung, sonst kann man nämlich nicht mit der Basisklasse operieren ohne zu wissen, was für abgeleitete Klassen dahinterstecken. Wenn man sagt, die Bedingung ist: Die Property ist readonly. Dann wäre ein Stetter ja ein aufweichen der Bedingung.

Genauso kann man eben aber auch sagen, der Setter ist eine Erweiterung um eine neue Funktionalität.

Da ich keinen Streit darüber wollte, habe ich diesen Punkt offen gelassen, denn man kann wirklich beides vom Konzept her rechtfertigen.

[Alexander Kornrumpf]

Ich bezog mich eher auf Compiletime-Fehler versus exzessives Benutzen von Exceptions.

[LaBerg]

Ich denke man kann beides mit dem Konzept der Verbung rechtfertigen mit dem Konzept der Verbung. Wenn davon ausgeht, dass eine abgeleitete Klasse eine Bedingung immer nur verstärken darf und niemals abschwächen. Das ist ein sehr wichtiger Grundstatz der Vererbung, sonst kann man nämlich nicht mit der Basisklasse operieren ohne zu wissen, was für abgeleitete Klassen dahinterstecken. Wenn man sagt, die Bedingung ist: Die Property ist readonly. Dann wäre ein Stetter ja ein aufweichen der Bedingung.

Ich muss meine Aussage von meinem vorherigen Post etwas korrigieren. Da ist nämlich ein Fehler drin.. Da war ich mit schreiben schneller als mit denken... :oops:

Richtig ist, dass man in Abgeleiteten Klassen Vorbedingungen nicht verstärken darf und Nachbedingungen nicht aufweichen darf. Damit kann man nur leider das gesagte nicht untermauern.

Aber einen anderen Punkt kann man vielleicht als Erklärung anführen. Eine readonly Property ist ja eine Einschränkung, wie ein private oder protected. Nur eben in dem Fall auf lesen und schreiben. In C++ kann man aus einer Protected Methode prlötzlich eine public machen. Sowas geht in C# auch nicht und da würde wohl keiner sagen, dass das eine unsinnige Einschränkung ist.


Ich persönlich finde Compilerfeher sinnvoller als Exceptions. Bei den Exceptions sucht man sich nämlich immer zu tode woran es denn liegt...

Im speziellen Fall ist es vielleicht besser die Property Readonly zu lassen und das Set als normale Methode zu implementieren. Die Frage ist auch immer wieviel Code packt man in die Properties und ab wann sollte man besser eine Methode schreiben. Wenn es viel zu bearbeiten gibt schreibe ich lieber eine Methode, weil das suggeriert auch gleich "hier wird viel gearbeitet". Die Properties haben immer den Eindruck einer simplen Zuweisung, die schnell geht.