protected

[Angelika_25]

Hallo ich habe folgende Klassen:

public class Rect {
	protected int width;
	protected int height;
	
	public Rect (int width, int height) {
		this.width=width;
		this.height=height;
	}

}

und

public class ColorRect extends Rect{
	protected String color;
	
	public ColorRect(String color, int width, int height) {
		super(width, height);
		this.color=color;
	}

}

Rect r4=new ColorRect(1024, 768, "Yellow");

Grundsätzlich wäre das in Ordnung, aber auf meinem Aufgabenblatt steht, dass das nicht geht,
weil kein Zugriff von außen auf color möglich ist.
Nur auf color nicht?
In der Klasse rect sind die Variablen doch auch protected?
Kann mir das mal einer erklären?


Viele Grüße

 

[The_S]

Du greifst ja auch nicht von außen auf eine der Attribute zu. Man kommt von außen (außer im selben Package) auch nicht auf die anderen protected Attribute.

 

[Der Müde Joe]

Controlling Access to Members of a Class (The Java™ Tutorials > Learning the Java Language > Classes and Objects)

Grunsätzlich:
private und access über public getter.

Nie mehr zeigen als nötig, Immer so wenig zeigen wie möglich.

 

[Tomate_Salat]

Zugriffsmodifizierer

[c]protected[/c] ist schon sichtbar für andere Klassen, aber eben nur für die, die sich im selben Paket befinden (=> also im selben Ordner)

 

[The_S]

Zugriffsmodifizierer

[c]protected[/c] ist schon sichtbar für andere Klassen, aber eben nur für die, die sich im selben Paket befinden (=> also im selben Ordner)

Oder für Kindklassen.

 

[Tomate_Salat]

Hätte ich dazu schreiben sollen, stimmt, geht aber auch aus dem Link hervor.

Edit besser formulieren hätte ichs auch können . Ja ich bin noch bei meinem ersten kaffee heute morgen, gebt mir Zeit wach zu werden

 

[Angelika_25]

Aber warum geht dann beispielsweise dieses:

ColorRect r2=new ColorRect(640, 480, "Green");

Was ist daran so anders wie bei dem Beispiel das nicht geht?

Ich steh glaub ich auf dem Schlauch...

 

[Der Müde Joe]

Jetzt muss ich genau nachfragen:

Was soll den nicht gehen? Oder was ist deiner Meinung nach falsch?

Es ist ein Konstruktoraufruf. Der Konstruktor ist public.

 

[Tomate_Salat]

Hallo ich habe folgende Klassen:

public ColorRect(String color, int width, int height)

ColorRect r2=new ColorRect(640, 480, "Green");

Nein mit dem Konstruktor kann das nicht gehen, wenn dann:

ColorRect r2=new ColorRect("Green",640,480);

und der Zugriffsmodifizierer von deinem Konstruktor ist public, also wieso sollte das nicht gehen?

 

[Angelika_25]

Also ich habe ein Blatt mit diesen Aussagen:

//in Ordnung
Rect r1=new Rect(800, 600);

//in Ordnung
ColorRect r2=new ColorRect(640, 480, "Green");

//geht nicht
ColorRect r3=new Rect(320, 240);

//in Ordnung
//Von außen kein Zugriff auf color möglich!
Rect r4=new ColorRect(1024, 768, "Yellow");

Diese wollte ich jetzt alle nachvollziehen und verstehen...


P.S.: Die Kommentare sind nicht von mir, sondern von dem Lehrer....

 

[Schumi]

Hier geht es wohl weniger um Sichtbarkeiten der Variablen als um Typhierarchien.
Galileo Computing :: Java ist auch eine Insel (8. Auflage) – 6.8 Vererbung

 

[Tomate_Salat]

Also ich habe ein Blatt mit diesen Aussagen:

//Von außen kein Zugriff auf color möglich!
Rect r4=new ColorRect(1024, 768, "Yellow");

Nun ja, ich denke der Aufruf erfolgt von einem anderen Paket aus, in diesem Falle ist [c]color[/c] in der Referenz nicht sichtbar für andere Objekte und kann dadurch von außen her nicht direkt (außer über setter o. andere Methoden, die ColorRect bereitstellt) verändert werden.
Ich veranschauliche mal anhand eines Strukturbaumes:

src
 |--Programm.java
 |--schule
         |- ColorRect.java
         |- Rect.java
         |- TestKlasse.java

Dabei liegt [c]TestKlasse[/c] im selben Paket(Schule) wie [c]ColorRect[/c] aber [c]Programm(.java)[/c] liegt außerhalb. [c]TestKlasse[/c] hat somit zugriff auf [c]protected[/c], wohingegen die Referenz in [c]Programm[/c] keinen hat:

Programm:

import schule.ColorRect;


public class Programm
{
	public Programm()
	{
		ColorRect cr	= new ColorRect(400, 300, "Red");
		// cr.color		= "blue"; <-- Geht nicht!
	}
}

schule.TestKlasse

package schule;

public class TestKlasse
{
	public TestKlasse()
	{
		ColorRect	cr	= new ColorRect(500, 400, "Green");
		cr.color 		= "Blue";
	}
}

MFG

Tomate_Salat

 

[Schumi]

Nun ja, ich denke der Aufruf erfolgt von einem anderen Paket aus, in diesem Falle ist [c]color[/c] in der Referenz nicht sichtbar für andere Objekte und kann dadurch von außen her nicht direkt (außer über setter o. andere Methoden, die ColorRect bereitstellt) verändert werden.

Da sie ein Objekt der Oberklasse referenziert, welche kein color attribut besitzt ist auf diesem Objekt die color Information nicht vorhanden, auch wenn sie beim instantiieren der spezialisierten Klasse gesetzt wird. Wie gesagt geht es bei der Aufgabe nicht um (Paket-)Sichtbarkeiten. Siehe auch http://www.java-forum.org/java-basics-anfaenger-themen/100136-polymorphie.html (da war ja TS auch schon aktiv )

 

[Tomate_Salat]

Ja ich war noch iwie auf das protected focusiert. [c]Rect[/c] kennt kein color und kann das damit auch nicht ändern.

Rect r4=new ColorRect(1024, 768, "Yellow");

sollte wohl auch eher so ausschauen

Rect r4=(Rect) new ColorRect(1024, 768, "Yellow");

[...] Siehe auch http://www.java-forum.org/java-basics-anfaenger-themen/100136-polymorphie.html (da war ja TS auch schon aktiv )

An dieser Stelle möchte ich nochmal an mein Kaffee-Problem erinnern :lol:

 

[Schumi]

Rect r4=new ColorRect(1024, 768, "Yellow");

sollte wohl auch eher so ausschauen

Rect r4=(Rect) new ColorRect(1024, 768, "Yellow");

Ein Cast auf eine Oberklasse/Interface brauchts nicht.

 

[Michael...]

Was der Kommentar soll, keine Ahnung:
//Von außen kein Zugriff auf color möglich!
zu mal da noch in Ordnung dabei steht.

Warum Variante 3 nicht gehen soll keine Ahnung??
Vielmehr sollte Variante 2 und 4 nicht gehen da es einen Konstruktor ColorRect(int, int, String) nicht gibt, sondern nur ColorRect(String, int, int)...
... sofern die im ersten Post aufgeführten Klassen tatsächlich so aussehen.

 

[Tomate_Salat]

Oh ich halt die klappe und hol mir einen 2ten Kaffe, ey das gibts nicht

zu meiner Verteidung: ich hab iwie in der morgendlichen Schlaftrunkenheit vergessen das Rect die Basis-klasse ist und nicht ColorRect

 

[Schumi]

Was der Kommentar soll, keine Ahnung:
//Von außen kein Zugriff auf color möglich!
zu mal da noch in Ordnung dabei steht.

Warum Variante 3 nicht gehen soll keine Ahnung??
Vielmehr sollte Variante 2 und 4 nicht gehen da es einen Konstruktor ColorRect(int, int, String) nicht gibt, sondern nur ColorRect(String, int, int)...
... sofern die im ersten Post aufgeführten Klassen tatsächlich so aussehen.

Naja, über das Rect kommt man halt nicht an color sondern erst nach einem möglichen Cast auf ColorRect. Das stimmt so dann schon. Und das das Konstruieren des Objektes so korrekt (= in Ordnung) ist ist ja unbestritten (wenn man mal von der inkorrekten Parameterfolge absieht... ;-) )

 

[Wortraum]

//in Ordnung
//Von außen kein Zugriff auf color möglich!
Rect r4=new ColorRect(1024, 768, "Yellow");
[/code]

Hier geht es nicht um Zugriffsmodifikatoren, sondern darum, Objekte und Vererbung zu verstehen.

Da ColorRect von Rect erbt, kann es alles, was auch Rect kann; man darf also der Variable vom Typ Rect ein ColorRect‐Objekt zuweisen. Rect kennt jedoch keine Variable color, und deshalb ist der Aufruf r4.color nicht erlaubt – auch wenn das Objekt dahinter diese Variable hat.