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 */ }
}
}
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 */ }
}
}
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;
}
}
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"); }
}
}
Genau. :)Nico Probst hat geschrieben:Oder möchtest du vermeiden das manche Abgeleiteten Klassen einen Setter bekommen?
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;
}
}
}
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.LaBerg hat geschrieben:Wie sinnvoll das ist eine Readonly Property auf einmal schreibbar zu machen, ist sicher auch fraglich.
Ein Wunsch, der in Meinen Augen einen wesentlichen Philosophieunterschied zwischen C++ und C# aufzeigt.Steffen Engel hat geschrieben:Dein Code spiegelt meine jetzige Loesung wieder.
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.LaBerg hat geschrieben:Wie sinnvoll das ist eine Readonly Property auf einmal schreibbar zu machen, ist sicher auch fraglich.
Das dachte ich mir auch schon, dass es daran liegen koennte.Alexander Kornrumpf hat geschrieben:Ein Wunsch, der in Meinen Augen einen wesentlichen Philosophieunterschied zwischen C++ und C# aufzeigt.
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.Steffen Engel hat geschrieben:Das dachte ich mir auch schon, dass es daran liegen koennte.Alexander Kornrumpf hat geschrieben:Ein Wunsch, der in Meinen Augen einen wesentlichen Philosophieunterschied zwischen C++ und C# aufzeigt.
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: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.