O
Anfänger001 schrieb:
Wäre doch praktisch nur eine Methode zu brauchen.
(Obwohls komisch aussieht)
Es gibt auch einige Bibliotheken, die das so machen. In Sprachen wie C# ist das meines Wissens über Properties gelöst, die sich genau so verhalten. Aber sie sind letztendlich nur Syntaxzucker über separate get() und set() Methoden.
Es ist hauptsächlich Konvention, dass man direkt am Namen der Methode erkennen kann, ob ein Objekt durch den Aufruf verändert werden kann oder nicht(stell dir vor, du suchst in einem Projekt mit 100.000 Zeilen Code einen Fehler und müsstest jedes mal überprüfen, ob Objekte irgendwie verändert werden...gruselig!). Wenn ich a.getValue(5) sehe, dann weiß ich, dass ich mir um den Zustand keine Sorgen machen muss, a kann nicht verändert werden. Dementsprechend sehe ich bei a.setValue(5,x) das a verändert wird und kann sofort vergleichen, ob das notwendig ist.
In C++ haben wir noch einen kleinen Helfer der sich const-correctness nennt. Kurz zusammengefasst: auf konstanten Objekten können nur Methoden angewandt werden, die es nicht verändern (also const-deklariert sind). Das hilft schon in 99% der Fälle und ich könnte sowas machen:
class A{
private:
double values[5];
public:
double value(unsigned int index )const{
return value[i];//const methode, value kann nur gelesen werden
}
double& value(unsigned int index ){
return value[i];
}
};
A a;
a.value(4)=100;//funktioniert nur, weil a nicht konstant ist.
std::cout<<a.value(4);
A const& b=a;//konstante Referenz auf a
b.value(4)=200;//kompiliert nicht! b ist konstant
std::cout<<b.value(4);//alles super!
Es sieht von außen genauso aus, wie du beschrieben hast, funktioniert aber besser. Es ist aber nicht perfekt, wie du bei a siehst. Wir können gerade beide Methoden aufrufen, obwohl wir das vielleicht nicht wollen. Es könnte also sein, dass wir a aus versehen verändern, ohne dass wir es sofort merken.
Es gibt noch andere Gründe, aber das führt hier zu weit
