Frage bzgl getter-Methode

Simon2

schorsch code schrieb:

...

Konrad Rudolph schrieb:

Zu hast recht, Schreibzugriff sollte über einen Setter erfolgen -- modifizierender Zugriff aber IMHO nicht unbedingt. Leider kann man das in C++ AFAIK nicht (oder nur sehr aufwendig) trennen.

Doch gerade in C++ kann man das sauber trennen. Es sind Java, C#, ..., die alle im Gegensatz zu C++ keine const correctness unterstützen.

Ich habe nicht wirklich den Unterschied zwischen "Schreibzugriff" und "modizierenden Zugriff" verstanden ... aber (oder evtl. genau deswegen) mir fällt nicht ein, wie man in C++ per const dazwischen unterscheiden könnte.

@Konrad: Meinst Du "Schreibzugriff" == "Zuweisung eines neuen Objektes"; "mod. Zuriff" = "verändern des internen Zustand des Objekts" ? ...

Gruß,

Simon2.

Ich vermute, mit modifizierendem Zugriff ist indirekter Schreibzugriff gemeint. Das heißt du holst (Lesezugriff) dir eine Teilmenge des Objektzustands (wie z. Bsp. mit der erwähnten w3c-DOM-Methode getElementsByTagName). Dann erst modifizierst du (Schreibzugriff) das Objekt, indem du schreibend auf das Geholte zugreifst.

finix

Konrad Rudolph schrieb:

Was soll mir der Code sagen?

War spät gestern. p sollte eine Referenz sein, get_participants eine Referenz zurückliefern. Als Beispiel für "öffentliche Datenkapselung", und gutes, nicht-redundantes Design sozusagen....

Konrad Rudolph schrieb:

Äh, ja. Was ist denn der Unterschied zwischen Schreibzugriff und modifizierendem Zugriff?

Schreibzugriff ist eine Zuweisung.

Und ein Schreibzugriff ist kein modifizierender Zugriff?

Badestrand

Hmmm... Interessante Diskussion, aber ich glaube ihr habt euch etwas verbissen...

Habt ihr schon mal drüber nachgedacht, dass es nicht so viel Sinn macht, eine Klasse als kompletten Vector-Wrapper zu implementieren?

Es ist sicherlich nicht dem Zweck entsprechend, einen Vector-Member zu haben und für jede der einzelnen Member-Funcs des Vectors einen Wrapper zu implementieren.
Genauso zweifelhaft finde ich es, den Vector praktisch als public zu deklarieren.

Wenn eine Klasse eine Reihe von Objekten verwalten soll, sollten eine Get, Add und Del-Methode doch reichen :xmas2:
Und wenn nicht, sollte man evtl über eine andere Datenkapselung nachdenken

Simon2

Badestrand schrieb:

...

Hast Du zufällig meinen Beitrag gelesen ?

Gruß,

Simon2.

Artchi

Sorry, aber irgendwie finde ich die Diskussion sinnlos. Ein Beispiel:

class A
{
  private:
    string name;
  public:
    string& getname();
    void setname(string);
}

Wie würdet ihr das hier lösen? string ist immerhin auch ein Container. Muß ich name jetzt auch nochmal kapseln?

Meiner Meinung nach kommt es darauf an, in welchem Kontext der in diesem Thread diskutierte Vector steht. Welchen Zweck/aufgabe soll er in der Klasse erfüllen? Dementsprechende würde ich ihn komplett kapseln (add, get und delete Methoden) oder einfach oder per einfachem get bereitstellen.

Übrigens, get-Methoden habe ich noch nie als "nur lesend" interpretiert. Get heißt für mich einfach nur, das ich etwas bekomme. Punkt. Wenn etwas "nur lesend" sein sollte, müsste man die Methode readX() benennen oder sowas.

Badestrand

Simon2 schrieb:

Hast Du zufällig meinen Beitrag gelesen ?

Öhh ja... Willst du damit sagen ich hätte genau das gleiche geschrieben?

Grüße

CStoll

Artchi schrieb:

Sorry, aber irgendwie finde ich die Diskussion sinnlos. Ein Beispiel:
class A
{
  private:
    string name;
  public:
    string& getname();
    void setname(string);
}
Wie würdet ihr das hier lösen? string ist immerhin auch ein Container. Muß ich name jetzt auch nochmal kapseln?

Kommt wohl darauf an, wie sich der Name nach außen präsentieren soll. Normalerweise behandelt man ja einen string als logische Einheit und dann reicht es aus, ihn als Ganzes rauszugeben.
(übrigens solltest du darüber nachdenken, die getname() const zu setzen, sonst ist deine Datenkapselung wieder futsch^*).

^* Ja, im einfachsten Fall reduziert sich die setname() auf ein einfaches "name=the_name;". Aber spätestens wenn du kontrollieren willst, was dort drin passiert, legst du dich gefährlich auf die Nase.

Artchi

Normalerweise behandelt man ja einen string als logische Einheit und dann reicht es aus, ihn als Ganzes rauszugeben.

Exakt! Und warum sollte das nicht auch bei einem vector der Fall sein?

Man kann nicht pauschal sagen, der vector muß 100% gekapselt werden. Man muß erstmal den Kontext und die fachlichen Anforderungen berücksichtigen. Manchmal leitet man ja sogar vector private ab, und nutzt ihn nicht als einfaches Member. Weil ich halt den vector in dem speziellen Fall einem ganz anderen Kontext sehe.

CStoll

Artchi schrieb:

Normalerweise behandelt man ja einen string als logische Einheit und dann reicht es aus, ihn als Ganzes rauszugeben.

Exakt! Und warum sollte das nicht auch bei einem vector der Fall sein?

Logisch gesehen ist es beim vector genauso. Allerdings liegt semantisch gesehen der Fokus des Vector auf seinen einzelnen Elementen, während der Fokus des Strings auf der Zeichenkette als Gesamtheit liegt.

Man kann nicht pauschal sagen, der vector muß 100% gekapselt werden. Man muß erstmal den Kontext und die fachlichen Anforderungen berücksichtigen. Manchmal leitet man ja sogar vector private ab, und nutzt ihn nicht als einfaches Member. Weil ich halt den vector in dem speziellen Fall einem ganz anderen Kontext sehe.

Und genau diesen Kontext hebelst du aus, wenn der getter eine Referenz auf deine internen Daten zurückgibt. Da kannst du dir gleich die Schreibarbeit sparen und die Daten public setzen - der Effekt ist der selbe.

Simon2

Badestrand schrieb:

Simon2 schrieb:

Hast Du zufällig meinen Beitrag gelesen ?

Öhh ja... Willst du damit sagen ich hätte genau das gleiche geschrieben?

Grüße

Sagen wir mal so: Da Du "ihr" geschrieben hattest war ich mir nicht ganz sicher, ob ich mitgemeint war.
... und da habe ich jetzt nicht so ganz verstanden, wo Deine Kritik an meinem Ansatz liegt.

Gruß,

Simon2.

Simon2

Artchi schrieb:

Sorry, aber irgendwie finde ich die Diskussion sinnlos. Ein Beispiel:
class A
{
  private:
    string name;
  public:
    string& getname();
    void setname(string);
}
Wie würdet ihr das hier lösen? string ist immerhin auch ein Container. Muß ich name jetzt auch nochmal kapseln?...

Gegenfrage: Wie würdest Du Deine Frage beantworten, wenn Du in der nächsten Version Deines Programms den Namen aus einer DB liest ? Oder intern doch lieber als vector<char> oder char[25] ablegen willst ?

Alle Aufrufer gehen inzwischen davon aus, dass sie mit doSomething(a.getname()) den Zustand von a ändern .....

Gruß,

Simon2.

eine wirklich interessante diskussion, da dachte ich ich frage die totale newbie sache die sich als einfach zu beantworten und glasklar darstellt, und dann kommt sowas dabei raus ( im positiven sinne )

worauf ich bei all den geposteten möglichkeiten nochmal hinweisen möchte, ist, dass es mir nicht darum ging, dass es jetzt unbedingt ein vector sein muss. mich würde das ganze schon eher datentyp-unabhängig interessieren.

da mich einige posts ehrlich gesagt ein wenig durcheinander gebracht haben, vllt nochmal der aufruf wie das ganze denn nun aussehen sollte und umzusetzen ist.

ein beispiel:

Test.h:

class Test {
 private:
    int value;
};

wie sähen jetzt die getter und setter auf int value sowohl in der Test.h als auch in der Test.cpp datei aus?

sollte hier jemand eine möglichkeit posten, wäre ich über eine begründung, vor oder nachteile, dankbar hilft sicherlich auch der diskussion

ich hoffe meine erneute anfrage kommt nun nicht total nervend rüber, auch möchte ich die diskussion dadurch keinesfalls beenden

danke @ alle beteiligten

Artchi

Ui ui, also native Datentypen, da ist die Situation auch schon wieder anders. Das ist ja halt der Witz an der Sache!

int getValue();
void setValue(int i);

Unterschied ist hier, das es keine Diskussion geben kann, weil man int bzw. native Typen nicht als Ref über- oder zurückgibt.

Wobei ich dann bei dieser Betrachtung schon wieder dem readonly-Gedanken bei get zustimmen muß. Denn implizit habe ich bei nativen Typen ohne Ref-Operator schon wieder nur eine readonly-Situation.

Würde mal sagen, die Readonly-Fraktion bzgl. getter hat gewonnen.

Konrad Rudolph

Artchi schrieb:

Wobei ich dann bei dieser Betrachtung schon wieder dem readonly-Gedanken bei get zustimmen muß. Denn implizit habe ich bei nativen Typen ohne Ref-Operator schon wieder nur eine readonly-Situation.

Ja, aber hier besteht auch gar nicht die Notwendigkeit einer Unterscheidung zwischen Modifikation und Zuweisung d.h. das Problem ergibt sich gar nicht erst.

Ich finde nicht, dass man pauschal alles über ein Messer scheren kann. Es mag sinnvoll sein, mit eigenen Klassen die POD-Funktionalität nachzustellen -- aber irgendwo sollte man eine Grenze ziehen.

Ein Member, das wenig Spiecher verbraucht, wird gewöhnlich durch den getter einfach rauskopiert:

//.h
class Test
{
public:
    int getValue() const;
private:
    int value;
};

//.cpp
inline int Test::getValue() const
{
    return value;
}

Solch kleine Methoden definiert man aber auch gerne direkt in der Klasse (.h Datei) und macht sie damit implizit inline.

Badestrand

test-mensch schrieb:

ich hoffe meine erneute anfrage kommt nun nicht total nervend rüber, auch möchte ich die diskussion dadurch keinesfalls beenden

Ist immer noch dein Thread

[Noch in der Vorschau]Ok, die Setter/Getter-Frage wurde geklärt^^[/]

@Simon2: Habe keine Kritik an deinem Ansatz, tut mir Leid wenn das so rüber gekommen ist! Mir kam es nur so vor als ob es nur noch darum ging, wie man am besten einen vector samt allen Members kapselt...

Simon2

Artchi schrieb:

Ui ui, also native Datentypen, da ist die Situation auch schon wieder anders. ...

Wieso ?

Kapselung ist Kapselung....

Gruß,

Simon2.

Simon2

Badestrand schrieb:

...
@Simon2: Habe keine Kritik an deinem Ansatz...

OK, dann sind wir uns einig und können uns auf :xmas1: freuen.

(Die smilies sind einfach süüüüüß).

Gruß,

Simon2.

Artchi

Simon2 schrieb:

Artchi schrieb:

Ui ui, also native Datentypen, da ist die Situation auch schon wieder anders. ...

Wieso ?

Kapselung ist Kapselung....

Ist mir auch klar! Ich bezog mich auf den technischen Aspekt! Du mußt meinen Beitrag als ein ganzes lesen, nicht nur die Einleitung einzeln betrachten.