Public/Private und wie importieren?

[A3XX]

HI

Zwei Fragen wieder:

a) Was ist der Unterschied zwischen Publik und Private? Also eigentlich verstehe ich das schon, bezieht sich ja immer darauf wo man siche gerade befindet oder? Eine private Variable in einer Methode ist nur in der Methode zugänglich aber eine private Variable in der Klasse für die ganze Klasse gelle?
Kann man eigentlich in einer Methode eine Variable so publik machen, dass sie auch für andere Klassen zugänglich ist?

Und eigentliche Frage dazu:
Wieso muss man gewisse Methoden (wie z.B. paint oder z.b. actionPerformed) public machen?

b) was bedeutet der Stern beim importieren?
z.B. import java.awt.event.*
aber wieso schreibt man dann java.applet.Applet und nicht java.applet.*
?

 

[Beni]

Du kannst nie in eine Methode "hineingreiffen", deshalb kann man von aussen auch keine Variablen einer Methode sehen (kommt noch hinzu, dass diese Variablen nur existieren, wenn die Methode am arbeiten ist).

Diese Methoden müssen public sein, damit sie von anderen Klassen aufgerufen werden können. (oder woher wird denn wohl "paint" aufgerufen ?)

Der * bedeutet: alles was in diesem Package ist (einfach eine Schreibweise für die Faulenzer).

Und die letzte Frage: das macht jeder wie er will.

 

[pogo]

methode die public sind sind im komplette package sichtbar.
private methoden sind nur in der aktuellen klasse sichtbar.

 

[L-ectron-X]

Das Schlüsselwort, das sich auf die Klasse bezieht, in der man sich gerade befindet heißt "this".
private und public Variablen gibts in Java nur außerhalb von Methoden, also im Klassenrumpf.
Variablen in Methoden, den so genannten lokalen Variablen werden diese Schlüsselwörter nicht vorangesetzt. Das würde zu einem Compiler-Fehler führen. Lokale Variablen werden nach Beenden der Methode in der sie programmiert sind wieder zerstört.
Die Schlüsselwörter public und private regeln die Zugriffsrechte/Sichtbarkeiten auf Instanzvariablen und Methoden.
Ist eine Variable oder Methode als public deklariert, ist sie von "außen" sichtbar, und es kann auf sie zugegriffen werden. Ist eine Variable oder Methode als private deklariert kann sie nur innerhalb der Klasse benutzt werden. Zugriffe von "außen" werden dann mit einem Compiler-Fehler quittiert.
Es ist richtig und guter Programmierstil, wenn nur Methoden einer Klasse auf ihre Instanzvariablen Zugriff haben.
Das heißt, dass die Instanzvariablen privat deklariert werden und damit nur die Methoden der Klasse in der sie deklariert sind Zugriff auf sie haben. Die Methoden können dann private oder public deklariert werden, je nach dem, ob sie von "außen" benutzt werden sollen oder nicht.

Die paint()-Methode aus java.applet.Applet ist deshalb in Deinen Programmen public zu programmieren, weil Du Deine Applets eben von java.applet.Applet ableitest. Deine Applet-Klasse hat also alle Eigenschaften und Methoden der überschriebenen Originalklasse geerbt. Um die Fähigkeit der paint()-Methode in Deinem Applet zu nutzen, musst Du sie überschreiben. Dazu schreibst Du in Deinen Applets den genauen Wortlaut der Originalmethode.
Also:

public void paint(Graphics g) {
    //was die Methode machen soll
}

Wenn Du sie private machen würdest, hättest Du in diesem Moment eine neue Methode deklariert, die nichts mehr mit paint() aus java.applet.Applet zu tun hat. In diesem Fall dürfte der Compiler schon melden, dass die Methode verkehrt überschrieben wurde.

Kann man eigentlich in einer Methode eine Variable so publik machen, dass sie auch für andere Klassen zugänglich ist?

Nein, das geht nicht. Das könnte auch zu Inkonsistenzen führen und das Programm schlicht weg unbrauchbar machen.

was bedeutet der Stern beim importieren?

Das Sternchen ist ein Platzhalter und steht für alle Klassen innerhalb eines Packages.
Wenn Du also java.awt.* importierst, machst Du dem Java-Compiler damit alle in dem Package java.awt untergebrachten Klassen bekannt. Gäbe es das Sternchen nicht, müsste jede zu verwendende Klasse in Deinem Programm extra aufgerufen werden, was Dir mehr Tipparbeit beschert.

L-ectron-X

 

[A3XX]

Danke erstmal für eure umfangreichen Antworten. Aber zwei Dinge noch:

a) Ja ich brauche ja mit Paint dinge aus applet.applet etc. Aber wenn ich paint private mache heisst das ja nur, dass paint einfach in dieser Klasse gebraucht werden kann aber das importieren und überschreiben sollte docha u so klappen? Das kapier ich nicht ganz wieso die public seni muss. Nur weil sie Dinge aus einer anderen Klasse erbt? Dann muss doch einfach die andere Methode public sein oder?! Da hab ich vermutlich nen Denkfehler aber bitte helft mir da auf die Sprünge

b) Ok das mit dem Sternchen dacht ich mir so, weil in MySQL ist es dasselbe (* = alles). Aber wieso importiert dann der autor java.awt.* und java.awt.event.*? Eigentilch sollte java.awt.* doch die event Dinge schon haben oder? Und wenn man das * benutzt, gibt es da nicht performanceeinbussen, wenn man nicht genau das richtige package importiert und stattdessen einfach kollektiv alles?

 

[bygones]

a) Ja ich brauche ja mit Paint dinge aus applet.applet etc. Aber wenn ich paint private mache heisst das ja nur, dass paint einfach in dieser Klasse gebraucht werden kann aber das importieren und überschreiben sollte docha u so klappen? Das kapier ich nicht ganz wieso die public seni muss. Nur weil sie Dinge aus einer anderen Klasse erbt? Dann muss doch einfach die andere Methode public sein oder?! Da hab ich vermutlich nen Denkfehler aber bitte helft mir da auf die Sprünge

Jede Methode die du überschreiben willst muss die selbe Signatur haben wie die zu überschreibende Klasse. D.h. eine public Methode zu überschreiben heißt das die Methode in deiner Klasse auch public sein muss.

b) Ok das mit dem Sternchen dacht ich mir so, weil in MySQL ist es dasselbe (* = alles). Aber wieso importiert dann der autor java.awt.* und java.awt.event.*? Eigentilch sollte java.awt.* doch die event Dinge schon haben oder? Und wenn man das * benutzt, gibt es da nicht performanceeinbussen, wenn man nicht genau das richtige package importiert und stattdessen einfach kollektiv alles?

Weil du mit dem * nur die Klassen in dem angebenen package, aber nicht deren unterpackages importierst !

 

[L-ectron-X]

OK, noch mal.
In der Klasse java.applet.Applet gibts eine Methode paint(), die dort bereits schon ererbt wurde. Nämlich von java.awt.Panel. Die erbte von java.awt.Container. Container erbte ihrerseits die paint()-Methode von java.awt.Component.
In allen Fällen ist die Methode public und muss, wenn sie in Deiner Klasse überschrieben werden soll, ebenfalls public sein. Wenn Du statt dessen die Methode als private deklarierst bekommst Du einen Compiler-Fehler. Beim Überschreiben von Methoden muss die Signatur und der Rückgabewert der überschriebenen Methode gleich der Signatur und dem Rückgabewert der Originalmethode sein. Als private deklarierte Methoden in einer Basisklasse können nicht überschrieben werden, da sie in der abgeleiteten Klasse (Subklasse) nicht sichtbar sind.

public void paint(Graphics g)

zu b)
Das Sternchen steht für die Klassen in einem Package nicht für weitere Packages die in diesem Package implementiert sind. Daher werden mit der Import-Anweisung...

import java.awt.*;

...auch nur die Klassen des AWT-Packages importiert. Die Klassen im darunterliegenden java.awt.event-Packages sind dem Compiler bis dahin noch verborgen.
Es kommt auch nicht zu Performance-Einbußen oder dazu dass die Klassen mehr Speicherplatz benötigen, wenn man die Klassen mit einem Sternchen importiert. Es geht hier nur um Bequemlichkeit.
Wenn man vom Importieren spricht, meint man eigentlich das Bekanntmachen von Klassen, die man benutzen möchte. Der Compiler erfährt nur, wo er die verwendeten Klassen findet, mehr nicht.

L-ectron-X

 

[bygones]

Es kommt auch nicht zu Performance-Einbußen oder dazu dass die Klassen mehr Speicherplatz benötigen, wenn man die Klassen mit einem Sternchen importiert. Es geht hier nur um Bequemlichkeit.
Wenn man vom Importieren spricht, meint man eigentlich das Bekanntmachen von Klassen, die man benutzen möchte. Der Compiler erfährt nur, wo er die verwendeten Klassen findet, mehr nicht.

Und wenn überhaupt dann ja nur beim compilieren, beim ausführen spielen die import anweisungen doch keine Rolle mehr - oder :?: ???:L

 

[L-ectron-X]

Die import-Anweisungen spielen beim Ausführen des Programmes keine Rolle, denn da hat der Compiler schon ein lauffähiges Programm erstellt um das sich jetzt der Interpreter kümmert. Hier ist der ClassPath und das JRE interessant.
Import-Anweisungen können in einem Quelltext angegeben werden, um sich viel Schreiberei zu ersparen.

import java.awt.*;

public class MyClass extends Frame {
//was das Programm tun soll
}

...ist das gleiche wie...

public class MyClass extends java.awt.Frame {
//was das Programm tun soll
}

Man muss im zweiten Beispiel eben nur immer die Packages angeben aus denen die Klassen stammen, die man benutzt.

L-ectron-X

 

[Semox]

Hallo L-ectron-X und Forum

Was ich dann nicht verstehe ist, wieso macht man sich dann überhaupt jemals die Mühe die Packages anzugeben wenn das nur bis kurz vor dem Compiler reichen soll?

Welcher Grund steht dem vor, daß die Java Entwickler die Paketangabe nicht längst hinausgeschmissen haben? Es muß einen Grund geben... Ich hoffe jemand mir kann das erklären. (-:

Liebe Grüße
SemoX

 

[Fu3L]

Hallo L-ectron-X und Forum

Was ich dann nicht verstehe ist, wieso macht man sich dann überhaupt jemals die Mühe die Packages anzugeben wenn das nur bis kurz vor dem Compiler reichen soll?

Welcher Grund steht dem vor, daß die Java Entwickler die Paketangabe nicht längst hinausgeschmissen haben? Es muß einen Grund geben... Ich hoffe jemand mir kann das erklären. (-:

Liebe Grüße
SemoX

Such mal in der Java-api nach der Klasse Date. Du wirst nicht nur eine finden. Welche soll der Compiler also nehmen? java.util.Date? java.sql.Date? Deshalb sagst du dem Compiler explizit, welche du haben möchtest, entweder durch

java.util.Date datum = new java.util.Date();

oder halt

import java.util.Date;

 

[Murray]

Packages schaffen Namensräume - so schafft man es, dass jeder Java-Entwickler seine Klasse nennen kann, wie er will: solange er ein eindeutiges Package verwendet, gibt es keine Nameskonflikte.
Gäbe es keine Packages, dann könnte es weder im JDK zwei Lists geben (java.awt.List und java.util.List), noch dürfte irgendwo auf der Welt jemand eine Klasse names List schreiben. Und noch schlimmer: SUN könnte niemals neue Klassen einführen, ohne Gefahr zu laufen, dadurch irgendein Programm auf der Welt nicht mehr funktionieren zu lassen, weil dort bereits eine Klasse dieses Namens existiert.

 

[Semox]

Hallo Murray

Danke für die Erklärung... =)

Liebe Grüße
SemoX

 

[Schandro]

Beim Überschreiben von Methoden muss die Signatur und der Rückgabewert der überschriebenen Methode gleich der Signatur und dem Rückgabewert der Originalmethode sein. Als private deklarierte Methoden in einer Basisklasse können nicht überschrieben werden, da sie in der abgeleiteten Klasse (Subklasse) nicht sichtbar sind.

Eine kleine Ergänzung dazu:

public class DeleteMe{
	public static void main(String[] args){

		new A(){
			public void überschreibMich(){}
		};
		new A(){
			protected void überschreibMich(){}
		};

		/*new A(){ // einziges was nicht geht
			private void überschreibMich(){}
		};*/


		new InnerA(){
			public void überschreibMich(){}
		};
		new InnerA(){
			private void überschreibMich(){}
		};
		new InnerA(){
			protected void überschreibMich(){}
		};
	}

	static class InnerA{
		private void überschreibMich(){}
	}
}

abstract class A{
	protected abstract void überschreibMich();
}

Die Sichtbarkeitstufe muss gleich oder höher sein zum überschreiben.