private ignorieren

[shiroto]

Yahoo~
Mir ist da neulich was aufgefallen, was meines erachtens nicht gehen dürfte. Ich zeig euch einfach mal nen Code.

public class MeineKlasse {
	private int x;
	// mögliche variablen
	// mögliche konstruktoren

	public void meineMethode(MeineKlasse mk) { // die methode könnte auch anders aussehen, wichtig ist dass sie ein objekt der eigenen klasse erwartet
		mk.x++; // das sollte nicht gehen..tuts aber
	}
	// mögliche methoden
}

Wie man sieht wird hier der private-status von x einfach ignoriert. Damit kann ein Objekt einfach in den Variablen eines anderen Objekts der selben Klasse rumpfuschen, was eindeutig gegen das Geheimnisprinzip verstößt.
Da Java aber eigentlich großen Wert auf Strukturiertheit legt frage ich mich: Haben die das einfach vergessen? Oder gibt es einen Grund, dass man das machen darf? Oo
Das ganze funktioniert auch Klassenübergreifend, wenn die Variablen protected und die Klassen in der selben Klassenhierarchie sind. Also meinetwegen:

public class MeineKlasse {
	protected int x;
	// mögliche variablen
	// mögliche konstruktoren

	public void meineMethode(MeineKlasse2 mk) {
		mk.x++;
	}
	// mögliche methoden
}

Damit könnte man sich schön sein Programm zerschießen, wenn man nicht vorsichtig ist, was in Java schon verdammt schwer ist.
Ist jetzt nicht so, dass meine Welt deswegen zusammenbricht, aber es wundert mich eben.

 

[maki]

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

 

[FArt]

Das ist sinnvollerweise so spezifiziert, denn die Zugriffe werden auf Klassen- und Packageebene, nicht auf Instanzenebene geprüft.

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

 

[Landei]

Du bist nicht der einzige, der das als Sicherheitsloch empfindet: In Scala gibt es einmal das "normale" [c]private[/c], das sich wie in Java verhält, und dann [c]private[this][/c], das Variablen nur der eigenen Instanz sichtbar macht, so wie es dir vorschwebt. Diese Lösung lässt sich also ohne weiteres auf der JVM realisieren. Über die Gründe, es bei Java wegzulassen, kann man nur spekulieren, ich tippe aber ganz stark auf "ist für Otto-Normalprogrammierer zu kompliziert" (was ich für eine ziemlich arrogante Einstellung halte).

 

[bygones]

Damit könnte man sich schön sein Programm zerschießen, wenn man nicht vorsichtig ist, was in Java schon verdammt schwer ist.

wer es schafft in seiner eigenen Klasse sich so zu verschiessen... naja... selbst schuld

 

[Wildcard]

Du bist nicht der einzige, der das als Sicherheitsloch empfindet

Da die Sichtbarkeitsmodifier kein Sicherheitskonzept darstellen, kann es auch kein Sicherheitsloch sein.

 

[Marco13]

Irgendwie passt das ein bißchen: heise online - Sichere Java-Programme mit "Fabric"
Wenn nicht: Ignorieren

 

[Landei]

Da die Sichtbarkeitsmodifier kein Sicherheitskonzept darstellen, kann es auch kein Sicherheitsloch sein.

Sicher kein Sicherheitskonzept im "kryptographischen" Sinne, aber als "Leitplanken" bei der Programmierung und compilergeprüfte Dokumentation. Man muss das nicht so eng sehen.