Im Konstruktor mit Settern auf private Attribute zugreifen - oder nicht?

[fuulf]

Hallo,

ich würde gerne wissen, welcher der beiden folgenden Implementierungen besser ist:


Variante 1:

public class MyClass {
  MyClass(int start) {
    setMember(start);
  }
  
  public void setMember(int value) {
    member = value;
  }

  public int getMember() {
    return member;
  }
  
  private int member;
}

Variante 2:

public class MyClass {
  MyClass(int start) {
    member = start;
  }
  
  public void setMember(int value) {
    member = value;
  }

  public int getMember() {
    return member;
  }
  
  private int member;
}

Die selbe Frage stellt sich dann nochmal für Methoden der Klasse. Allgemein frage ich mich also: sollte man auch innerhalb der eigenen Klasse mit Settern und Gettern auf private Eigenschaften zugreifen?


Viele Grüße

 

[Gast2]

Innerhalb einer Klasse finde ich es nicht soo wichtig die Daten über setter zu manipuilieren. Wenn man seiner eigenen Klasse schon nicht traut, wem dann

Im Konstruktor mit Settern auf private Attribute zugreifen - oder nicht?

Wie gesagt siehe oben. Wobei man bei Konstruktoren darauf achten sollte dass man ausschließlich Methoden aufruft die final sind, ansonsten kannst du Probleme bei abgeleiteten Klassen bekommen.

 

[fuulf]

Vielen Dank schonmal

Wir wurden halt ziemlich eindringlich auf die Wichtigkeit von Daten-Kapselung hingewiesen, da dachte ich schon...

Wobei man bei Konstruktoren darauf achten sollte dass man ausschließlich Methoden aufruft die final sind, ansonsten kannst du Probleme bei abgeleiteten Klassen bekommen.

Das ist so, weil sonst die aufgerufenen Methoden überschrieben werden können, was den Konstruktor ruinieren könnte?


Viele Grüße

 

[Illuvatar]

Was für Variante 1 sprechen würde:
Der Zugriff über getter/setter kann ja eventuell später einmal nützlich sein, wenn man die Menge der gültigen Parameter einschränken möchte, also z.B. im setter noch ein [c]if (value >= 0)[/c] einbaut.
Wenn man Variante 1 verwendet, muss man diesen Check dann eventuell nicht auch noch im Konstruktor einbauen (dort sollen ja vermutlich dann auch keine ungültigen Werte übergeben werden können).

 

[gassssssst]

Ich würde es so machen, so hast du nämlich auch tatsächlich Datenkapselung, im Gegensatz zu deinen beiden Varianten:

public class MyClass {
  private int member;

  MyClass(int start) {
    member = start;
  } 
}

 

[bygones]

du arbeitest dann mit methoden, dessen objekt noch vielleicht noch nicht initialisiert wurde

 

[Gast2]

Das ist so, weil sonst die aufgerufenen Methoden überschrieben werden können, was den Konstruktor ruinieren könnte?

Das ist ein Grund. Aber es gibt noch nen gravierenden Grund:
Der Konstruktor der Oberklasse wird vor dem Konstruktor der Subklasse aufgerufen. Wenn du jetzt aus dem Oberklassenkonstruktor eine Methode der Subklasse aufrufst wird diese VOR dem Konstruktor der Subklasse aufgerufen und du kannst falsch Werte erhalten.

Hier nen Beispiel:

public class ConstructorDemo {

	public static void main(String[] args) {
		new Subclass(42);
	}
	
	abstract static class Parent {
		Parent() {
			int i = getTheValue();
			System.out.println(i);
		}
		
		abstract int getTheValue();
	}
	
	private static class Subclass extends Parent {

		private final int value;
		
		Subclass(int value) {
			this.value = value;
		}
		
		@Override
		int getTheValue() {
			return value;
		}
	}
}

Als Ausgabe erhälst du 0, und nicht die erwartete 42.
Das kommt vielleicht nicht allzu oft vor, aber man sollte dran denken wenn man sowas macht.

EDIT:
Viel zu spät :/

 

[fuulf]

Was für Variante 1 sprechen würde:
Der Zugriff über getter/setter kann ja eventuell später einmal nützlich sein, wenn man die Menge der gültigen Parameter einschränken möchte, also z.B. im setter noch ein if (value >= 0) einbaut.
Wenn man Variante 1 verwendet, muss man diesen Check dann eventuell nicht auch noch im Konstruktor einbauen (dort sollen ja vermutlich dann auch keine ungültigen Werte übergeben werden können).

Also könnte man ja eigentlich schon sagen, dass das Prinzip der Datenkapselung auch innerhalb der Klasse zumindest teilweise greift? (In dem Sinne, dass man nur einmal definieren muss, wie und was man setzen darf und dann immer auf diese Definition zurückgreifen kann)

Also wenn man auf der sicheren Seite sein will (d.h. wenn man Qualität über Bequemlichkeit stellt) sollte man sich generell immer an Variante 1 halten?

Ich sollte auch noch dazu sagen, dass ich bald eine Klausur schreibe. Und da gebe ich im Zweifelsfall lieber den Opportunisten mit der Lehrbuchlösung. Und das wäre dann also Variante 1, oder?


Viele Grüße

 

[Gast2]

Also wenn man auf der sicheren Seite sein will (d.h. wenn man Qualität über Bequemlichkeit stellt) sollte man sich generell immer an Variante 1 halten?

Ja, Variante 1 ist wohl die saubere. Aber die Methoden müssen dann final sein.

 

[fuulf]

du arbeitest dann mit methoden, dessen objekt noch vielleicht noch nicht initialisiert wurde

Ich verstehe die Aussage nicht

 

[Gast2]

Schau dir meinen Code von oben an, der zeigt das Phänomen dass das Objekt noch nicht "fertig" ist.

 

[fuulf]

Ja, Variante 1 ist wohl die saubere. Aber die Methoden müssen dann final sein.

Sollte man Getter und Setter eigentlich immer als final deklarieren?

 

[bygones]

Sollte man Getter und Setter eigentlich immer als final deklarieren?

wenn sie nicht ueberschrieben werden sollen ja... wie jede andere methode auch

 

[Gast2]

Sollte man Getter und Setter eigentlich immer als final deklarieren?

Ja, sollten sie. Sind sie in deinem Beispiel aber nicht

 

[fuulf]

Ja, sollten sie. Sind sie in deinem Beispiel aber nicht

Also muss ich mir das ab heute mal angewöhnen!

Aber noch mal zu deinem Beispiel, das ich immer noch zu verstehen versuche. Ich dachte am Anfang, es würde damit zusammenhängen, dass value als final deklariert wurde, aber es klappt auch so. (Zeile 18)

Dann habe ich mich gefragt, wo denn überhaupt die 0 her kommt. Ich glaube, das ist so:

Bevor er mit Zeile 20 anfangen kann, muss er bei 8 starten. Und dann ist in Zeile 9 das Problem, dass getTheValue() gebraucht wird, aber nicht da ist. Und da wird dann ohne Fehlermeldung einfach mal so die 0 geholt - und dann auch ausgegeben. Weil value in Zeile 18 als final deklariert wurde, bleibt value auch für immer eine 0, aber hätte man in Zeile 18 auf das final verzichtet, dann würde sich value schon noch auf die 42 ändern, oder?

Also wenn ich das alles richtig verstanden hätte. Wäre das dann nicht ein Verstoß gegen das Prinzip der geringsten Verwunderung. Also ich meine, dann müsste man sich doch fragen: Warum macht Java denn sowas?!


Viele Grüße

 

[Gast2]

Nein, mit dem final hat das nichts zu tun. Das Problem ist einfach folgendes:

Der Konstruktor von Parent wird VOR dem Konstruktor von Subclass aufgerufen. Im Konstruktor wird getTheValue() aufgerufen (auf der Subklasse) und der Wert von value wird zurückgegeben. Da dort aber noch kein Wert gesetzt wurde wird der default wert zurückgegeben, der ist hier 0. Danach erst wird der Konstruktor von Subclass aufgerufen und

value

wird auf 42 gesetzt.

Wenn du folgende main verwendest siehst du das auch:

public static void main(String[] args) {
	Subclass sc = new Subclass(42);
	System.out.println(sc.value);
}

Die Ausgabe ist:

0
42

 

[fuulf]

Gut, dann ist das schonmal doch nicht so schlimm von Java, wie ich dachte

Aber wäre es nicht trotzdem besser von Java, wenn Java generell den Aufruf einer Methode (wie beim Beispiel getTheValue()) verbietet, wenn zu dem Zeitpunkt noch nicht der Konstruktor der Klasse, in der die Methode definiert wird, aufgerufen worden ist? Oder wenn Java halt eben erst den gebrauchten Konstruktor (hier also den von Subclass) aufrufen würde? Ich meine, Java muss doch merken, dass es sich bei der 0 nur um einen Standardwert handelt, bei dem es äußert fragwürdig erscheint, dass der Programmierer den auch wirklich haben wollte, oder?


Viele Grüße

 

[Gast2]

Nein das geht nicht. Java hat zur Compilezeit von Parent keinerlei Informationen darüber welche Klassen von Parent ableiten und ob da eventuell Methoden überschrieben werden. Du kannst ja die Basisklasse auch seperat kompilieren und später in nem anderen Projekt Subklassen dazubauen. Bei den IDEs kannst du aber einstellen, dass du ne Warnung bekommst wenn im Konstruktor Methoden aufgerufen werden die nicht final sind.

 

[fuulf]

Ich denke, jetzt ist alles klar soweit

Vielen Dank nochmal!