[XDestroy]

Hallo zusammen.

Ich bin momentan am umsteigen von C++ auf Java.
Dabei ist mir eine Sache aufgefallen. In Eclipse kann ich auswählen, ob eine Klasse public oder default sein soll. in c++ dagegen habe ich immer nur class verwendet. meine frage ist daher, was ich nun unter java nehmen muss?
ich vermute (vermute!^^) mal das public eben eine öffentlich klasse macht (d.h. man kann von außen auf alles zugreifen was im objekt dann ist?) und default eine art private/protected ist. ich frage mich jetzt was ich als nehme um den gleichen effekt zu haben wie bei class in c++. oder kann ich auch einfach nur class schreiben? der grund wie ich jetzt darauf komme ist, das eclipse danach eben fragt und ich mich jetzt frage, was ich für die klasse nehme, die die main funktion enthält. in c++ war main halt immer klassenlos, was bei java ja nicht ist. das ist neuland für mich. wie muss die klasse sein in der die main ist?

danke!! =)


gruß
xdestroy

[Graumagier]

XDestroy sagte:

in c++ dagegen habe ich immer nur class verwendet.

In C++ gibt's aber ebenso eine Unterteilung in öffentliche und private Elemente.

Deine Vermutungen sind prinzipiell richtig, auch wenn du dich vlt. mal in Java einlesen solltest

Es wird grundsätzlich unterschieden zwischen Zugriffsspezifizierern für Klassen und zwischen solchen für Klassenelementen. Für Klassen gibt es "" und "public", wobei "public" bedeutet, dass auf die Klasse aus allen Paketen heraus zugegriffen werden kann, während man auf mit "" spezifizierte Klassen nur aus dem selben Paket zugreifen kann, in dem die Klasse deklariert ist.
Für Klassenelemente gibt es "", "public", "private" und "protected". Die Bedeutungen von "" und "public" sind die selben wie bei den Klassen. "private" bedeutet das selbe wie "private" bei C++, und "protected" bedeutet Zugriff vom selben Paket und aus abgeleiteten Klassen.

[Rika]

"" ist quasi "package-local".

Aber "protected" impliziert dieses nicht, du kannst wirklich nur von abgeleiteten Klassen darauf zugreifen.


Generell gilt aber, daß das für Applications sowieso nicht forciert wird, der Check liefert immer "true" zurück. Es gehört trotzdem zum guten Stil, der Compiler forciert es idR und für Applets wird es auch forciert.

[Graumagier]

Rika sagte:

Aber "protected" impliziert dieses nicht, du kannst wirklich nur von abgeleiteten Klassen darauf zugreifen.

Tatsächlich? Ich hab' hier im "Java 5 Kompendium" zweimal widersprüchliche Aussagen und finde auch bei Google nichts dergleichen. Würde IMO ja auch nicht wirklich Sinn machen, "protected" nicht als Erweiterung von "" zu behandeln.

Dieser Beitrag wurde von Graumagier bearbeitet: 05. Januar 2007 - 19:29

[Rika]

Class A {
  protected int a=1;
}

Class B {
  private int b=a;
}

Class C {
  private int c=(new A()).a;
}

C gibt 'nen Compile-Error und mit modifizierten Modifiern in einem AppletSecurityContext einen AccessError.

Und es ist logisch, weil es eine triviale Reihenfolge nach Strenge gibt: public - package-local/"" - protected - private. Daß "protected" von der Wortbedeutung her strenger sein sollte als "" (gar nichts), sollte auch irgendwie klar sein.

[Graumagier]

Rija sagte:

C gibt 'nen Compile-Error und mit modifizierten Modifiern in einem AppletSecurityContext einen AccessError.

Hast du das ausprobiert? Eigentlich sollte B einen Fehler bringen (logisch, es sei denn im Falle von class B extends A {}) und C sollte funktionieren. Ist zumindest bei mir der Fall.

[Witi]

Zitat

Aber "protected" impliziert dieses nicht, du kannst wirklich nur von abgeleiteten Klassen darauf zugreifen.

Ich sehe protected immer als eine Erweiterung von private an. Der Zugriff ist sowohl von der eigentlichen Klasse als auch von den abgeleiteten Klassen aus möglich.

Zitat

C gibt 'nen Compile-Error und mit modifizierten Modifiern in einem AppletSecurityContext einen AccessError.

Wie Graumagier schon richtig sagte, gibt auch B einen Error. Es fehlt in beiden Fällen das Schlüsselwort "extends".
Wäre das der Fall, würde nur noch C einen Fehler ausspucken. Da mit "new A()" ein neues Objekt erzeugt und somit nicht mehr auf die geerbte Membervariable zugegriffen wird.

[Rika]

Ja, ne, ich meine, wenn bei C eben kein extends steht. Da C im gleichen Package liegt wie A, wäre der Zugriff bei "" / package-local möglich, aber bei protected ist er nicht möglich.

Das extends bei B hatte ich nur vergessen.

Zitat

Ich sehe protected immer als eine Erweiterung von private an. Der Zugriff ist sowohl von der eigentlichen Klasse als auch von den abgeleiteten Klassen aus möglich.

Du hast von der eigentlichen Klasse aus immer Zugriff auf die Membervariablen, egal mit welchem Modifier. Daher stellt sich bei den Modifiern nur die Frage, welchen zusätzlichen Zugriff man erlauben möchte.

Bei Packages hat man übrigens noch die Möglichkeit, das jeweilige Package in einem JAR zu versiegeln (sealed). Dann ist es nicht mehr möglich, weitere Klassen zu dem Package hinzuzufügen. java.lang ist prinzipiell sealed und javax.security und einige weitere sind per Default sealed.