Property set in Objekthierarchie

DarthZiu

Moin!

Ich weiß nicht, unter welchem Titel ich das posten soll, daher hier gleich mein Problem:

Bisher habe ich:

class Irgendwas()
{
    uint a;
    public uint A() {
        get { return a; }
        set { 
                a = value;
                DoSomethingWithA(); }

    uint b;
    public uint B() {
        get { return b; }
        set { 
                b = value;
                DoSomethingWithB(); }

    // noch ein paar Properties mehr davon

    void DoSomethingWithA() { /* ... */ }
    void DoSomethingWithB() { /* ... */ }      
}

Nun möchte ich die Properties aber in einer Klasse zusammenfassen:

class myProperties
{
    uint a;
    public uint A() {
        get { return a; }
        set { a = value; }

    uint b;
    public uint B() {
        get { return b; }
        set { b = value; }
}

class Irgendwas()
{
    public myProperties P;

    void DoSomethingWithA() { /* ... */ }
    void DoSomethingWithB() { /* ... */ }  
}

Jetzt ist die Frage, von ich meine Methoden DoSomethingWithA & B aufrufen kann oder soll. Geht das jetzt noch so elegant wie im obigen Code? Ich möchte, dass sich die Benutzung der Klasse nicht ändert, aber zurzeit sehe ich keine andere Möglichkeit als eigene Methoden zum Setzen der Properties zu implementieren.

Vielen Dank für eure Antworten.

Sowas?

class myProperties
{
    public uint A { get; set; }

    public uint B { get; set; }
}

class Irgendwas()
{
    private myProperties P;

    public uint A 
    {
        get { return P.A; }
        set 
        {
                P.A = value;
                DoSomethingWithA(); 
        }
    }

    public uint B 
    {
        get { return P.B; }
        set 
        {
                P.B = value;
                DoSomethingWithB(); 
        }
    }

    void DoSomethingWithA() { /* ... */ }
    void DoSomethingWithB() { /* ... */ }  
}

Allerdings frage ich mich was der Sinn des ganzen sein soll.

DarthZiu

An diesen Ansatz hatte ich auch schon gedacht. Allerdings stört mich wieder die ganze doppelte Verwaltung (im Sinne von setzen in class Irgendwas und dann wieder setzen in class Properties).

O.o schrieb:

Allerdings frage ich mich was der Sinn des ganzen sein soll.

Nun, der Sinn soll das Kapseln der Properties (es handelt sich um Einstellungen für ein Gerät) sein. Ich finde es deutlich einheitlicher

myObject.A = 5;

zu schreiben, als:

myObject.setA(5);

weil C# ja nunmal dieses Property-Konzept hat und die meisten Klassen-internen Variablen so gesetzt werden. Deswegen möchte ich das möglichst einheitlich halten, auch wenn beide Codebeispiele intern das Gleiche bewirken.

Der Grund, warum ich die Properties in Klassen kapseln will ist, dass es noch eine ganze Reihe mehr gibt, die in verschiedene Kategorien gehören. Also möchte ich für jede Kategorie eine eigene Klasse mit den entsprechenden Variablen haben. Weil ich später dafür auch Zuweisungsoperatoren und Copy-Konstruktoren brauche.

hiho,
Im Titel steht etwas von Hierarchie, im Text ist davon jedoch nichts zu finden.
Wie hast du dir das jetzt konkret gedacht.

1)Möchtest du die Möglichkeit haben das Objekte von ein und der Selben klasse
ein austauschbares Verhalten haben, 2) oder möchtest du von einer Basisklasse
verschiedene Ableitungen, welche jeweils eine Konkrete Interpretation deiner Eigenschaften haben?

DarthZiu

Ka-Mensch schrieb:

1)Möchtest du die Möglichkeit haben das Objekte von ein und der Selben klasse
ein austauschbares Verhalten haben, 2) oder möchtest du von einer Basisklasse
verschiedene Ableitungen, welche jeweils eine Konkrete Interpretation deiner Eigenschaften haben?

Weder noch. Ich suche nur einen eleganten Weg, wie ich

[Aufrufer] ---> [Objekt]

in

[Aufrufer] ---> [Objekt] <---> [Objekt, dass die Eigenschaften kapselt]

ändern kann. Mir geht's wirklich nur darum, ob ich Aktionen, die nach dem Setzen von Eigenschaften ausgeführt werden sollen, in irgendwie elegant in die setter einbauen kann, oder ob ich Methoden dafür schreiben muss.

Was stört dich an dem Beispiel, dass ich gegeben habe? Im Endeffekt sind das Get- und Set-Methoden, nur dass die Syntax anders und in meinen Augen "schöner" ist als tatäslich SetA() und GetA() Methoden zu haben.

DarthZiu

Folgendes stört mich daran:

Wenn ich die Propertyklasse irgendwo mit Werten fülle (zum Beispiel beim Auslesen aus einer Datei), kann ich sie der "Irgendwas"-Klasse zwar zuweisen, aber alle notwendigen Methodenaufrufe muss ich immernoch zu Fuß ausführen.

Aber nach einigem grübeln komme ich auch zu dem Schluß, dass sich das nicht anders lösen lässt und dein Ansatz der beste Kompromiss ist. Dann werd ich das so implementieren.

Du willst also Änderungen an den Werten der Property-Klasse in der Irgendwas-Klasse mitbekommen? Dann wirst du wohl den Weg über Events gehen. Du kannst dir dazu auch mal das INotifyPropertyChanged-Interface anschauen. Ist zwar auch nicht gerade elegant, aber eine bessere Möglichkeit gibt es soweit ich weiß nicht.

DarthZiu

Okay, danke für den Hinweis. Werd ich mir mal ansehen.

Wenn du also nichts spezielles vorhast und einfach nur eine Möglichkeit suchst die Einstellungswerte deines Geräts zu sammeln,
verstehe ich sowieso nicht wieso du das unbedingt in einer Klasse kapseln musst.
Ist doch nur eine Auflistung von Einstellungswerten.

Gestalte MyProperties doch als private Stuktur von Irgendwas.
Über deine Properties der Irgendwasklasse greifst du dann mit den relevanten
Absicherungen bzw. Zusatzfunktionalitäten auf die Elemente der Struktur zu.

Und Nebenbei bemerkt, entsprich das was du beschreibst das Streben
nach einem austauschbaren Verhalten, wenn du die diese Properties erst
woanders füllen lässt und dann deinem Objekt zuweist.

Alternativ solltest Du Dir mal das Interface-Konzept von C# anschauen.

Du machst für jede Kategoriegruppe ein Interface und läßt deine Klasse mehrere Interfaces implementieren. Also so ca:

interface IBasis
{
   uint A { get; set; }
   uint B { get; set; }
}

interface IVolume
{
    uint Vol { get; set; }
}

class Irgendwas : IBasis, IVolume
{
    public uint A { get; set; }

    public uint B { get; set; }

    public uint Vol { get; set; }
}

Später kannst Du dann immer gezielt nur die Interfaces benutzen die Du brauchst.