setter im Konstruktor einbauen?

[Thisor]

Hey, wollte mal fragen ob beides dasselbe macht? Wenn ja, an welches sollte man sich halten?

Konstruktor ohne setter:

public class Fahrzeug {
private  int leistung;
private String hersteller;

public Fahrzeug(int leistung, int hersteller){
this.leistung = leistung;
this.hersteller = hersteller;
}
}

Konstruktor mit setter:

public class Fahrzeug{

private int leistung;
private String hersteller;

public Fahrzeug(int leistung, String hersteller){
setLeistung(leistung);
setHersteller(hersteller);

}
}

 

[thecain]

kommt drauf an was im setter steht 😉 Bei "Standard" Settern, ja.

An ersteres solltest du dich halten.

 

[Thisor]

Thanks!
edit: wie sieht denn ein nicht-Standard-setter aus?

 

[MarzAttak]

Es macht schon Sinn, auch klassenintern die Setter zu verwenden. In ihnen kann man die Validation der übergebenen Werte an einer Stelle bündeln.

 

[thecain]

Nein, macht es nicht. Ich erbe von der Klasse, überschreibe den Setter. => Wenn ich nicht weiss, dass der setter auch im Konstruktor aufgerufen wird, bin ich aufgeschmissen.

Validierungen können im Konstruktor auch so gemacht werden, am Besten über einen Builder, bei komplexeren Objekten

Ein "Standard" Setter ist einfach

public void setXXX(Bla xxx) {
   this.xxx = xxx;
}

/e Im Konstruktor würde ich nur private Methoden aufrufen. (Macht bei einem Setter wenig Sinn)

 

[Thisor]

Validierung ist was?
@thecain ein nicht-"Standard" Setter vorführen bitte 😀

Dieses hier

Code (Java): public void setXXX(Bla xxx) {
this.xxx = xxx;
}

ist die Variantie die ich kenne und benutze.

 

[thecain]

public void setXXX(int xxx) {
  if (xxx > 5) {
     this.xxx = 333;
  }
  else {
      this.xxx = xxx;
   }
}

Validierung ist prüfen ob alle angaben gültig sind.

 

[MarzAttak]

@thecain:
Vielen Dank, wieder was gelernt. In meinen Büchern steht es z.T. anders.

 

[stg]

etwas allgemeiner kann man folgende Regel nennen:

Im Konstruktor sollten niemals überschreibbare Methoden aufgerufen werden. Das heißt nur Aufrufe von Methoden, die static, private oder final sind, können geduldet werden. (Aber auch hier ist Vorsicht geboten!)

Ist die Erzeugung eines Objekts aber recht aufwändig (besteht nicht nur aus dem einfachen setzen von Attributen) und erfordert den Aufruf zahleicher "Hilfsmethoden", so ist das oft ein Indiz dafür, dass eine Factory(-Methode oder -Klasse) zur Erzeugung verwendet werden sollte.