field public/private wann

[Guest]

hallo,

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?

 

[Der Müde Joe]

>wann sollte man ein feld aber public machen?

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...

 

[Gast]

also gibt es keinen sinvollen einsatz instanzvariablen public zu setzen?

 

[Der Müde Joe]

ausser static final fällt mir im Moment keiner ein..

 

[mahe]

Wenn man das macht dann meistens aus Bequemlichkeit.

Bei nicht öffentlichen Klassen welche kaum Funktionalität bieten und hauptsächlich dem Zusammenfassen von Variablen dienen ist das durchaus legitim.

 

[Landei]

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)

 

[musiKk]

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.

 

[0x7F800000]

(etwa eine Vector3d-Klasse für 3D-Anwendungen)

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.

Aber bereits bei sowas: http://java.sun.com/j2se/1.4.2/docs/api/java/awt/GridBagConstraints.html kriege ich irgendwie ein mulmiges gefühl :autsch:

 

[Marco13]

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.

 

[0x7F800000]

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?

 

[musiKk]

Aber bereits bei sowas: http://java.sun.com/j2se/1.4.2/docs/api/java/awt/GridBagConstraints.html kriege ich irgendwie ein mulmiges gefühl :autsch:

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.

 

[Marco13]

Man sollte sich also SEHR genau überlegen, ob das Sinn macht.

Wozu genau soll man einen Listener an einem 3D-Vektor brauchen? ???:L

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 ... )