denn sinn des private modifiers habe ich, denke ich, verstanden. er erlaubt den zugriff von "außen" auf fields eines objektes zu "verbieten" und ermöglicht so eine kapselung, z.B. indem get/set Methoden irgenwelche prüfungen vornehmen und nicht jeder wild das feld ändern kann wie er will.
wann sollte man ein feld aber public machen? d.h. soll nicht gerade verhindert werden, dass auf felder "einfach so" zugegriffen werden kann und ein unkontrolliertes modifizieren der werte dadurch erlaubt ist? d.h. sollte nicht am besten immer private genutzt werden?
Grob gesagt: Gar nie.
Für public static final Felder schon.
Gibt ja noch was dazwischen, protected bzw package-protected, je
nach dem ob man Felder vererben lassen will (oder besser gesagt
den Zugriff darauf, den vererbt werden auch private Felder) oder
ob man die Felder im package veröffentlichen will.
Generell:
So wenig wie möglich, nur soviel wie nötig...
public höchstens bei static final (wie schon erwähnt), oder wenn es auf das letzte Quentchen Performance ankommt (etwa eine Vector3d-Klasse für 3D-Anwendungen)
Bei Parameterobjekten könnte man das machen. Da man damit nur lange Parameterlisten verhindern will, ist eine eventuelle Fehlerprüfung (wie sie in Settern ja vorkommen kann) dort fehl am Platz.
Also das ist nur ein Fall, wo ich sagen würde, dass public Member nicht schaden und nicht, dass sie unbedingt verwendet werden sollten. IDEs generieren Getter und Setter ja auch automatisch. Aufwand hätte man dadurch also keinen großen.
in diesem konkreten fall kommt es imho auch darauf an, dass dieses Objekt schon wesentlich älter als 400 Jahre ist, und sich seitdem an den member-variablen nichts verändert hat. Außerdem sind dort eh alle werte ausnahmslos zulässig, und werden es auch immer bleiben, daher braucht man da nicht mal sicherheitshalber irgendwelche setter einzubauen.
Gerade oder auch in bezug auf das Beispiel von Vector3f (wie es in der Java3D vecmath Bibliohek heißt) : Mit public-Variablen macht man sich die Möglichkeit kaputt, einen Listener für Änderungen an dieser Variable zu basteln. Man sollte sich also SEHR genau überlegen, ob das Sinn macht.
Gerade oder auch in bezug auf das Beispiel von Vector3f (wie es in der Java3D vecmath Bibliohek heißt) : Mit public-Variablen macht man sich die Möglichkeit kaputt, einen Listener für Änderungen an dieser Variable zu basteln. Man sollte sich also SEHR genau überlegen, ob das Sinn macht.
Wozu genau soll man einen Listener an einem 3D-Vektor brauchen? ???:L Wenn sich in irgendeinem spiel irgendwas in Bewegung setzt, dann kann man solche ereignisse imho auch auf einer höheren ebene abfangen, da braucht man jetzt nicht wirklich jede koordinate bei jeder veränderung zu überprüfen. Oder kannst du bitte eine Anwendung nennen, wo das essentiel notwendig wäre? :bahnhof: Ist dir evtl. beim basteln von Swogl etwas aufgefallen?
Das ist ja eben ein solches Parameterobjekt. Der einzige Grund, dass es existiert, ist, ein Paar Variablen zu bündeln, und diese an einem Stück irgendwo hinzuschieben. Die Validierung der entsprechenden Daten geschieht dann dort.
Da hat jemand SEHR genau überlegt, und ist zu dem selben Schluss gekommen, wie du :wink: Das ist eines der SEHR wenigen Gegenbeispiele.
(Wenn man ein "kompliziertes" (schlecht dokumentiertes) Programm hat, wo auf einmal irgendein Dr*cks-Vector3f irgndwo ein "NaN" enthält, und man gerne wüßte, wo das herkommt, geht zwar das eklige Debuggen los, aber das ist kein wirkliches Argument. Man könnte sich zwar noch andere Gründe ausdenken, aber ... wenn einem diese public x,y,z nicht passen, dann kann man ja seine eigene Vector3f-Klasse verwenden ... )
