Ich habe eine Klasse, die verschiedene Member enthält. Diese lassen sich über Getter zurückgeben (und im UI anzeigen). Jetzt ist mein Problem: Wenn ich auch noch Setter für die Klassenmember einbaue, dann verliere ich doch jegliche Kontrolle über die Daten, oder? Ich frage das, weil die Klassenmember Listen darstellen, die nicht komplett geändert werden sollen, sondern nur leicht modifiziert werden sollen.
Ich habe mir schon überlegt, entweder Funktionen in die Klasse einzubauen, die das Bearbeiten der Liste ermöglichen oder eine Art Wrapper-Klasse zu erstellen, die eben solche Funktionen bereitstellt. Wie würdet ihr das lösen?

Grüße,

daersc

Hallo Forum,

Ich habe eine Klasse, die verschiedene Member enthält. Diese lassen sich über Getter zurückgeben (und im UI anzeigen). Jetzt ist mein Problem: Wenn ich auch noch Setter für die Klassenmember einbaue, dann verliere ich doch jegliche Kontrolle über die Daten, oder? Ich frage das, weil die Klassenmember Listen darstellen, die nicht komplett geändert werden sollen, sondern nur leicht modifiziert werden sollen.
Ich habe mir schon überlegt, entweder Funktionen in die Klasse einzubauen, die das Bearbeiten der Liste ermöglichen oder eine Art Wrapper-Klasse zu erstellen, die eben solche Funktionen bereitstellt. Wie würdet ihr das lösen?

Grüße,

daersc

Kann man so nicht sagen. Kommt drauf an, was du KONKRET vor hast.

Wenn ich auch noch Setter für die Klassenmember einbaue, dann verliere ich doch jegliche Kontrolle über die Daten, oder? Ich frage das, weil die Klassenmember Listen darstellen, die nicht komplett geändert werden sollen, sondern nur leicht modifiziert werden sollen.

Ich würde auf jeden Fall nur jene Funktionen zur öffentlichen Schnittstelle hinzufügen, die sinnvoll sind und deren Aufruf erlaubt ist. Wenn du irgendwo lediglich Lesezugriff brauchst, nimmst du eben nur einen Getter. Um genauer zu antworten, müsste man allerdings mehr über dein Problem wissen.

drakon schrieb:

Du kannst ja den Setter auch einfach leer lassen, dann wird nichts gemacht..

Warum das? Dann lieber gleich keinen Setter anbieten. Wenn ich SetXY() aufrufe, erwarte ich, dass XY dem von mir angegebenen Wert angepasst wird.

class Begegnung {
    // Zeiger auf Teams und Ergebnis
};

typedef std::list<Begegnung> Runde;
typedef std::list<Runde> Verlauf;

class Tournament {
    Verlauf m_verlauf;
    // ...
};

Pro Runde soll ein Team selbstverständlich nur einen Gegner haben - Ein Team darf pro Runde also nur in einer Begegnung auftauchen.
Wenn ich nun einen Setter schreiben würde, liese sich das ja kaum kontrollieren, ob dieses Kriterium eingehalten wurde.

drakon schrieb:

Du kannst ja den Setter auch einfach leer lassen, dann wird nichts gemacht..

Warum das? Dann lieber gleich keinen Setter anbieten. Wenn ich SetXY() aufrufe, erwarte ich, dass XY dem von mir angegebenen Wert angepasst wird.

Klar, aber ich wollte damit sagen, dass er die volle Kontrolle hat, was der Setter macht. Und eben, wenn er möchte kann er auch einfach mal nichts aktualisieren.

Oftmals reicht die einfache Zuweisung als Setter, aber es gibt Fälle, wo man halt eni sehr spezielles Verhalten haben will. Und da kann es auch vorkommen, dass der Setter nichts macht (ob er leer ist, eine Bedingung enthält oder mittels Präprozessor gefüllt willt spielt dann keine Rolle).

Ob es bei ihm sinnvoll kann ich nicht sagen, aber die Kontrolle hat man mit einem Setter auf jeden Fall.

Pro Runde soll ein Team selbstverständlich nur einen Gegner haben - Ein Team darf pro Runde also nur in einer Begegnung auftauchen.
Wenn ich nun einen Setter schreiben würde, liese sich das ja kaum kontrollieren, ob dieses Kriterium eingehalten wurde.

Dafür sollte ja meines erachtens die Klasse Begegnung selber zuständig sein. Da würde ich nichtmal einen Getter anbieten sondern die Listen nur Intern verwalten. Sobald du die Listen irgendwie nach aussen gibst, kann man von dort ein Add, Delete etc machen. Ggf solltest du noch weiter kapseln. Eine begegnung besteht doch sicherlich aus einen Match/Spiel etc. Irgendwas wo zwei Teams direkt gegeneinander Spielen. Damit besteht eine Runde aus 1-* solcher Matches. Runde könnte auch wieder eine Klasse sein. Die selbstständig abprüft ob eingetragene Matches Gültig sind.

Sobald du die Listen irgendwie nach aussen gibst, kann man von dort ein Add, Delete etc machen.

Nein, so stimmt das leider nicht.
Deine Aussage trifft nur auf nicht konstante Referenzen auf den Member zu. Sobald ich eine const-Referenz oder (am besten) ne Kopie zurück gegeben wird, kann man von außen nicht einfach die Liste oder deren Elemente manipulieren, resp. tut dies ohne die verwaltende Klasse zu verändern. (jaja, const_cast, aber solche Doldies gehören einfach durch plötzlich auftretende Runtime-Errors bestraft :P).

Fedaykin schrieb:

Sobald du die Listen irgendwie nach aussen gibst, kann man von dort ein Add, Delete etc machen.

Nein, so stimmt das leider nicht.
Deine Aussage trifft nur auf nicht konstante Referenzen auf den Member zu. Sobald ich eine const-Referenz oder (am besten) ne Kopie zurück gegeben wird, kann man von außen nicht einfach die Liste oder deren Elemente manipulieren, resp. tut dies ohne die verwaltende Klasse zu verändern. (jaja, const_cast, aber solche Doldies gehören einfach durch plötzlich auftretende Runtime-Errors bestraft :P).

Stimmt, hier trifft mich das ich lange kein C++ mehr gemacht habe. Dennoch halte ich eine bessere Kapselung in mehrere Klassen sinnvoller aber das ist wohl wieder persönliche Geschmackssache des Programmierers.