public, private, protected und "default access" -

[ulr!ch]

Hi JavaGemeinde,

ich habe hier ein paar grundlegende Anfängerfragen:
Bruce Eckels schreibt in 3. Ed. Rev. von "Thinking in Java":

Java uses three explicit keywords to set the boundaries in a class: public, private, and protected. Their use and meaning are quite straightforward. These access specifiers determine who can use the definitions that follow. [...]
Java also has a “default” access, which comes into play if you don’t use one of the aforementioned specifiers. This is usually called package access because classes can access the members of other classes in the same package, but outside of the package those same members appear to be private.

a) Das bedeutet als vier verschiedene Varianten, die in absteigender Performanz so anzuordnen sind?
private -> protected -> "default" access -> public

b) Wenn jetzt z. B. ein JTextField habe, macht es einen Unterschied in der Performanz, ob ich es
- im Konstruktor oder später irgendwo in der Klasse aufrufe?
- ich es mit "private" versehe?
- ich es mit "private static" versehe?

Ehrlich gesagt, verstehe ich die Unterschiede nicht sonderlich gut; hat jemand dazu einen verständlichen Text, der klare Ratschläge gibt?
Danke für alle Hinweise,

by<e Ulrich

 

[Roar]

a) private -> default -> protected -> public
b) - nö
- nö
- jo

 

[ulr!ch]

a) private -> default -> protected -> public
b) - nö
- nö
- jo

Thx, für die schnelle Antwort, aber so verstehe ich das nicht.
Wenn private performanter ist als default (siehe a), wieso ist dann b/ 2. Spiegelstrich "nö"?
Kann ich das als static formulieren, ist ja eigentlich nur ein blödes Objekt für die GUI.

Für Anregungen weiterhin dankbar,
by<e Ulrich

 

[Roar]

hä? was haben zugriffsmodifier mit der performanz zu tun? dein programm wird doch nicht schneller dadurch. die auflistung ist lediglich die sichtbarrkeit in aufsteigender form.

du kannst alles als static formulieren wenn du nix besseres zu tun hast

 

[ulr!ch]

hä? was haben zugriffsmodifier mit der performanz zu tun? dein programm wird doch nicht schneller dadurch. die auflistung ist lediglich die sichtbarrkeit in aufsteigender form.

Jetzt bin ich aber Buff, baff? :wink: naja, du weißt schon
Guido Krüger schreibt in der 3. Auflage seines "Handbuchs der Java-Programmierung", das übrigens für Leute mit dem schmalen Geldbeutel (Schüler, Studenten & Co) auf der Seite: http://www.javabuch.de/ kostenlos in der html-Version verfügbar ist im Kapitel Performance-Tuning (genauer 49.2.2)

Methoden des Typs final und private werden am schnellsten ausgeführt, insbesondere bei aktiviertem JIT.

Da steht auch eine Tabelle mit den gemittelten Geschwindigkeiten der unterschiedlichen Methodenaufrufe (schau's dir doch mal an).

By<e Ulrich

 

[Roar]

hmmja klingt logisch, je kleiner der zugriff, desto weniger muss der interpreter nach überschriebenen methoden suchen, aber dass man heutzutage noch große spürbare unterschiede feststellen kann bezweifel ich, da würd ich mir lieber um ein schönes design kümmern als ein paar ns geschwindigkeitsvorteil

und *räusper*:

Alle Messungen wurden mit dem JDK 1.2 Beta 4 auf einem PentiumII-266 unter Windows 95 vorgenommen.

 

[André Uhres]

Die eigentliche Frage ist doch wann man welche Zugriffsbeschränkung wählen sollte.
Hier einige Richtlinien:
private ist für Attribute,
public für public-Methoden,
protected für Hilfsmethoden.

 

[bygones]

Die eigentliche Frage ist doch wann man welche Zugriffsbeschränkung wählen sollte.
Hier einige Richtlinien:
private ist für Attribute,
public für public-Methoden,
protected für Hilfsmethoden.

1. ist klar
2. eine katze ist eine katze ist eine katze
3. hä ? wieso protected bei Hilfsmethoden ? was sind Hilfsmethoden ? und warum protected ???

 

[Roar]

public für public-Methoden,

2. eine katze ist eine katze ist eine katze

ich nehm protected nur wenn ich unterklassen hab die die variablen/methoden benutzen, ansonsten immer private

 

[André Uhres]

Mit public-Methoden meine ich natürlich Methoden die öffentlich bekannt sein sollen (dachte ihr versteht englisch :lol: ).
Im Gegenstatz dazu stehen Helper-Methoden die immer protected sein müssen wenn die Klasse wiederverwendbar sein soll.
Man kann ja nicht im voraus wissen wie ein Entwickler die Klasse verwenden möchte und welche Methoden er überschreiben muss :wink: .

 

[bygones]

Mit public-Methoden meine ich natürlich Methoden die öffentlich bekannt sein sollen (dachte ihr versteht englisch :lol: ).

ach ne....

Im Gegenstatz dazu stehen Helper-Methoden die immer protected sein müssen wenn die Klasse wiederverwendbar sein soll.
Man kann ja nicht im voraus wissen wie ein Entwickler die Klasse verwenden möchte und welche Methoden er überschreiben muss :wink: .

ich weiß zwar immer noch nicht was du mit Helper Methoden meinst. aber ich stimme dir einfach mal nicht zu ;-)

Man soll den Scope einer Variable / Methode so gering wie möglich halten. D.h. die erste Wahl ist IMMER private. Nur auf Verdacht zu programmieren ob irgendwann vielleicht mal irgendwer welche Methoden braucht bzw überschreibt zeigt eher von schlechtem Design. Es sollen Schnittstellen definiert werden, alle andere Zugriffe werden nicht erlaubt....

 

[thE_29]

Das einzige was wirklich fehlt ist "friend"

So wie in C++!

Ich häts heute schon wieder mal gebraucht!

Die Lib kann nur von der Lib verändert werden!

Außer 1 Programm sollte das können, bzw nur 1 Klasse...

Toll?!? Wie mache ich das ... geht net..

Hab ne public Methode geschrieben und die kann jetzt wieder von jedem verwendet werden (


Wäre für so eine "friend" Einführung in Java 6!

 

[SnooP]

Bau's dir doch selbst ... verhinderste das Ganze halt über ne Exception...

 

[Bleiglanz]

was bei der Diskussion immer zu kurz kommt und kaum ein Anfänger wirklich kapiert

Fall1: bei einem im stillen Kämmerlein selbst geschrieben Programm (über das man volle Kontrolle hat) und das keinerlei Beziehung zu irgendwas anderem hat ist es fast völlig egal welche modifier man verwendet. man könnte z.B. immer pubic nehmen

Die Verwendung von public/private/protected dient hier vor allem der Vermeidung von Fehlern und der Klarheit


Fall2: man programmiert was das ganz oder zu Teilen von anderen genutzt wird. z.B. Klassen, die in zwei oder mehr unabhängigen Projekten gemeinsam genutzt werden (von anderen Programmierern, am anderen Ende der Welt, Jahre später,...)

in dem Fall können diese "anderen Programmierer" alle public Methoden verwenden, man sagt deshalb sie "sind Teil der API" oder auch "öffentlich"; das Problem dabei ist, dass man später an diesen public-Eigenschaften nichts mehr ändern kann, da dann alle "abhängigen" Klassen umgeschrieben und neu kompiliert werden müssen usw. usf

=> deshalb ist es in dem Fall ziemlich wichtig, sich die "Veröffentlichung" einer Methode via public (oder protected) sehr gut zu überlegen

 

[André Uhres]

Helper-Methoden sind alle Methoden die in der Klasse sind um irgendwelche Funktionen
dieser Klasse zu implementieren.
Beispiele für eine Dialog-Klasse: buildContents(), buildMenu(), handleOKBtn(), handleSomeBtn(),...

Jetzt will ich z.B. die Funktionalität von handleOKBtn() ändern und den Rest der Klasse
wiederverwenden. Wenn diese Methode private ist, müsste ich die ganze Klasse neu implementieren,
also das Rad neu erfinden.

Andererseits, wenn alle diese Helper-Methoden protected anstatt private sind,
könnte ich einfach die Bedeutung der Methode handleOKBtn() neu definieren und die
ganze Klasse wiederverwenden.

Wenn du Klassen entwickelst die andere benutzen werden, kannst du nie sicher sein
was sie aus der Klasse machen werden. Aber wenn es dein Ziel ist die
Wiederverwendbarkeit zu fördern, dann wird deine Klasse erweiterbar indem du die
Helper-Methoden protected machst. Zudem gibst du vor der Öffentlichkeit keine
Sicherheit preis, weil protected die Benutzer daran hindert die Methode direkt zu
gebrauchen. Andererseits haben diejenigen die von deiner Klasse erben Zugang zu diesen
Helper-Methoden. Allgemein musst du jedoch davon ausgehen dass die Leute, die die
Klasse erweitern, wissen was sie tun. Aber sogar wenn sie es nicht wissen, das Schlimmste
was sie tun können ist dass sie ihre abgeleitete Klasse kaputtmachen.

Zusammenfassend ist es besser private für Attribute zu benutzen - public für
öffentliche (Interface)-Methoden und protected für Helper-Methoden.
Das gibt deiner Klasse einen Maximum an Flexibilität, ohne die Kapselung aufzugeben.