Warum sind public-Variablen böse?

Mal ne Frage: Warum sind public-Membervariablen in Klasse böse und in PODs nicht?

Bin gespannt auf eure Antworten...

mfg,

Artudeetu

Jester

Die Suchfunktion liefert Dir dazu sicher jede Menge Ergebnisse!

MfG Jester

Warum sind public-Membervariablen in Klasse böse

Sie sind weder gut noch böse, nur ungekapselt. Das führt dazu, dass diese als object.public_member oder pObject->public_member direkt im sonstigen Sourcecode auftauchen. Damit kann man nicht einfach innerhalb der Klasse den Aufbau komplett ändern, weil man nun immer nachschauen muss, wo die public Variablen benutzt wurden.

Konkretes Bsp: Klasse Teilchen mit folgenden Attributen: Masse, Geschwindigkeit, Ladung, Radius, ..., Impuls, ...

Im Sourcecode steht jetzt eine Formel mit teilchen_Elektron.Impuls, und Du willst jetzt intern den Impuls als Attribut löschen, dann hast Du dort ein Problem!

Kapselst Du aber die Attribute über eine public-Methode getImpuls(), dann ist das kein Problem:

vorher:
getImpuls() { return Impuls; }

nachher:
getImpuls() { return Masse*Geschwindigkeit; }

Im Sourcecode verwendest Du vorher und nachher:
teilchen_Elektron.getImpuls()

Das ist der Sinn der Kapselung. Man will die internen Informationen der Klasse "verstecken", damit man diese im Sourcecode nicht verwendet. Diese Technik spart eine Menge Sucharbeit, und Klasse und sonstiger Code können von verschiedenen Personen gewartet werden.

operator void

Was mir gerade so einfällt...
- Öffentliche Elementvariablen können nicht gegen Veränderungen geschützt werden, die den Klassenzustand verletzen würden (datum.monat = 13;)
- Man kann zwischen öffentliche Variablen und den Benutzer der Klasse keine Indirektion mehr zwischenschalten, in Zugriffsfunktionen kann man je nach Bedarf jeglichen Code hinzufügen (siehe Impuls-Beispiel weiter oben)
- Klassen sollen allgemein keine Variablensammlungen sein, sondern ein zusammenhängendes Verhalten modellieren (das steckt auch ein Bisschen im Impuls-Beispiel)

Bashar

Es wird aber immer wieder Klassen geben, die kein Verhalten haben und blosse "dumme" Datenansammlungen sind. Dafür nimmt man dann am besten struct.

oder einen Namespace:

namespace MyDummyVariables
{
double X;
double Y;
//...
}

int main()
{
double light_velocity = MyDummyVariables::X ;
}

Bashar

Namespaces sind aber, wenn man es so sieht, Singletons. Klassen kann man beliebig oft instanziieren.

rüdiger

außerdem kann das nuetzlich sein, wenn du den Code auf eine andere Platform portierst und sich dort das Verhalten der Klasse aendern muss und du die Variable zB. nur simulierst.

Walli

Man muss es imho von Situation zu Situation entscheiden. Wenn man echt keine Zeit hat um getter/setter zu schreiben und der Code nicht wiederverwendet wird dann geht es auch mal so. Aber OOP ist das nicht wirklich.

rüdiger

Wenn man echt keine Zeit hat um getter/setter zu schreiben

lol

Walli

Wieso lol? Nervig ist das mit den gettern/settern schon, obwohl einige IDEs dir viel Arbeit abnehmen! Klar, man verbringt nur einen Bruchteil der Zeit damit den Code zu schreiben, deswegen zieht das Argument mit der Zeitersparnis nicht wirklich.

Namespaces sind aber, wenn man es so sieht, Singletons.

Dann könnte man Klassen leicht vereinzeln:

class X{...};

namespace Singleton
{
 X alone_in_the_dark;
}

int main()
{
  Singleton::alone_in_the_dark; 
}

junix

Ist zwar etwas C++Builder-Spezifisch, lässtm ana ber den Teil über __property weg,so ist das halb so wild:
http://www.c-plusplus.net/forum/viewtopic.php?t=39302

-junix