# Enum und dann setter Setzen?



## rider (1. Sep 2009)

Hallo, 
ich habe ein Enum:


```
public enum Status
	{
		Erledigt,
		Offen		
	}
```

nun möchte ich mittels set-Methode das Enum auf "Erledigt" setzen.
Wie geht das ? (Einrichtung ist der Klassenname)


```
einrichtung.setStatus = "Erledigt";
```
Die Anführungszeichen sind Quark denke ich!
Sorry, habe davor noch nie wirklich mit Enums gearbeitet!


----------



## tfa (1. Sep 2009)

[c]einrichtung.setStatus = Status.Erledigt;[/c]
Oder besser [c]Status.ERLEDIGT[/c].


----------



## bygones (1. Sep 2009)

[c]einrichtung.setStatus = Status.Erledigt;[/c]
waere es aber nicht sinvoller da zu haben:
[c]einrichtung.setStatus(Status.Erledigt);[/c]


----------



## maki (1. Sep 2009)

Erledigt und Offen sind Objekte (soz. Singletons) des Enums (Klasse) Status.


```
einrichtung.setStatus(Status.Erledigt);
```

Enums sollte man übrigens komplett Groß schreiben 

nmachtrag: Kopierten Fehler korrigiert.


----------



## rider (1. Sep 2009)

Ok, ich hab hier eine Methode! Auch "ApaErledigt" ist ein Enum mit 2 Werten (offen und erledigt)!
Wenn ApaErledigt auf erledigt gesetzt wurde, dann soll eben auch der Status auf erledigt gesetzt werden!



```
public void erledigtEinrichtung(){
		
		Einrichtung einrichtung = new Einrichtung();
		
		if (einrichtung.getApaErledigt() == einrichtung.ApaErledigt.Erledigt)
		{
			einrichtung.setStatus(Status.Erledigt);
		}
	}
```

Stimmt das so?


----------



## bygones (1. Sep 2009)

rider hat gesagt.:


> ```
> if (einrichtung.getApaErledigt() == einrichtung.ApaErledigt.Erledigt)
> ```


das schaut n bisschen danach aus als ob du das selbe zweimal vergleichst ? ... sagen kann dir das aber keiner

ich vermute mal eher


```
if (einrichtung.getApaErledigt() == Status.Erledigt)
        {
            einrichtung.setStatus(Status.Erledigt);
        }
```

nur leider laesst dein Code jegliche Vermutung zu und ist so leider nicht zu beurteilen...


----------



## Spacerat (1. Sep 2009)

maki hat gesagt.:


> Erledigt und Offen sind Objekte (soz. Singletons) des Enums (Klasse) Status.


OT: Hat da jemand das DP Singleton immer noch nicht verstanden? Erledigt und Offen sind *zwei* Instanzen der Klasse Status und deswegen KEINE Singletons, nicht einmal sozusagen. Enum sagt aus, das es genau nur diese beiden Instanzen der Klasse Status gibt. Nur mal so zur Info, damit nicht wieder eine Grundsatzdiskussion über Singletons vom Zaun bricht.


----------



## bygones (1. Sep 2009)

Spacerat hat gesagt.:


> OT: Hat da jemand das DP Singleton immer noch nicht verstanden? Erledigt und Offen sind *zwei* Instanzen der Klasse Status und deswegen KEINE Singletons, nicht einmal sozusagen. Enum sagt aus, das es genau nur diese beiden Instanzen der Klasse Status gibt. Nur mal so zur Info, damit nicht wieder eine Grundsatzdiskussion über Singletons vom Zaun bricht.


wenn schon Haarspalterei dann richtig ;-)
maki meinte ja _sozusagen_ und das ist nicht identisch mit _ist gleich_


----------



## maki (1. Sep 2009)

Ja ist ja gut... werde das S- Wort aus meinen Vokabular streichen


----------



## Spacerat (1. Sep 2009)

bygones hat gesagt.:


> wenn schon Haarspalterei dann richtig ;-)
> maki meinte ja _sozusagen_ und das ist nicht identisch mit _ist gleich_


Hab' ich gelesen und in meinem Text auch berücksichtigt. Würde man bei einigen Dingen nicht diese Haare spalten, würden sie direkt falsch verstanden. Makis fehlgeleitete "Assoziation" ist ein gutes Beispiel.
@Maki: Ist aber kein Grund vor dem Verständnis von Singletons zu kapitulieren.


----------



## maki (1. Sep 2009)

@Spacerat

Ich habe ein falsche Aussage getroffen bez. Singletons.

Zufrieden? Oder noch mehr überflüssige Offtopic Diskussion über ein Thema das eigentlich keines ist?


----------



## tfa (1. Sep 2009)

Die Begriffsverwirrung gibt's auch woanders. In Spring kann man Beans als "singleton" (scope) erzeugen, was auch nicht das geringste mit einem GoF-Singleton zu tun hat. Der Begriff ist nicht geschützt. Aber ihn so wenig wie möglich zu erwähnen, ist schon ein guter Ansatz.


----------



## rider (1. Sep 2009)

Ok: nochmal ausführlicher:
In der Klasse "Einrichtung" gibt es 2 Enums:


```
public enum ApaErledigt
	{
		Erledigt,
		Offen		
	}
	@Column(name="apa_erledigt",length=8,nullable=false)
	@Enumerated(STRING)
	private ApaErledigt apaErledigt;
```


Und



```
public enum Status
	{
		Erledigt,
		Offen		
	}
	@Column(name="status",length=8,nullable=false)
	@Enumerated(STRING)
	private Status status;
```



So:
Wenn ApaErledigt auf "Erledigt" gesetzt wird, dann soll sich auch der Status in "Erledigt" ändern. Ich denke das ist nun deutlich??
Wie sieht dann die Implementierung der Methode aus?


----------



## Spacerat (1. Sep 2009)

```
public void setApaErledigt(ApaErledigt status)
{
  this.apaErledigt = status;
  if(status == ApaErledigt.Erledigt) {
    setStatus(Status.Erledigt);
  }
}

public void setStatus(Status status)
{
  this.status = status;
}
```
@maki: Zufrieden? Klar... schon bei deinem vorherigen Post


----------



## maki (1. Sep 2009)




----------



## rider (3. Sep 2009)

Jetzt mal noch eine andere Frage:

Nun mag ich noch  eine Methode, die mir das ganze überprüft.... Geht das denn auch mit den den GETTERN?



```
public boolean istApaErledigt()
{
  if(getApaErledigt == ApaErledigt.Erledigt) {
    return true;
  }
}
```

Oder wie mache ich die If- Abfrage dann?


----------



## Spacerat (3. Sep 2009)

klar geht das. Ist aber keine Getter-Methode . Was noch geht wäre:
	
	
	
	





```
public boolean istApaErledigt()
{
  //          \/\/ nicht getApaErledigt!
  return apaErledigt == ApaErledigt.Erledigt;
}
```
Eine Getter-Methode sähe so aus:
	
	
	
	





```
public ApaErledigt getApaErledigt()
{
  return apaErledigt;
}
```


----------



## Leroy42 (3. Sep 2009)

rider hat gesagt.:


> ```
> public boolean istApaErledigt()
> {
> if(getApaErledigt == ApaErledigt.Erledigt) {
> ...


Das funktioniert so nicht da im Nicht-true Fall ja gar nichts zurückgegeben wird.


----------



## bygones (3. Sep 2009)

Leroy42 hat gesagt.:


> Nicht-true Fall


verwegenerweise koennte man auch false Fall sagen :lol:


----------



## rider (4. Sep 2009)

würde es auch so gehen?
"Einrichtung" ist die Klasse in der das Enum ist!


```
public boolean isApaErledigtErledigt()
	{
		Einrichtung.ApaErledigt apaErledigt;
		if(apaErledigt == Einrichtung.ApaErledigt.Erledigt)
		{
			return true;
		}
		
		return false;
	}
```


----------



## tfa (4. Sep 2009)

Ja, aber wieso probierst du es nicht aus?
Die Lösung von Spacerat finde ich allerdings einfacher zu lesen.


----------



## rider (4. Sep 2009)

Nein!
das sind doch nun 2 verschiedene Methoden!
Einmal setzt er es, wenn der Fall eintritt
und die letztere Methode überprüft es einfach nur, ob der Fall eingetreten.


----------



## Spacerat (4. Sep 2009)

@tfa: Danke...
@TS: ... anzunehmen, das es so geht. Ich habe bisher angenommen, dass die Methoden in die Klasse Einrichtung implementiert werden sollen. Getter, Setter und Statusabfragen machen eigentlich ja auch nur dort Sinn, wo auch die Variablen (meistens "private") definiert wurden. In anderen Klassen kann man, zu gunsten der Lesbarkeit, die Enums seit Java 5 (JRE1.5) statisch importieren. Die Variablen dürfen in der Klasse Einrichten dann aber nicht mehr "private" sein, was oben genannte Methoden allerdings wieder unsinnig machen würde.
@Edit: ähm... Enums gibt es ja auch erst seit Java 5... Die JRE passt also...


----------



## rider (4. Sep 2009)

Nein, die Methoden werden in der *Service - Klasse *implementiert.
Die Variablen sind private definiert und in der Klasse "*Einrichtung*"

```
public enum ApaErledigt
	{
		Erledigt,
		Offen		
	}
	@Column(name="apa_erledigt",length=8,nullable=false)
	@Enumerated(STRING)
	private ApaErledigt apaErledigt
```

Getter + Setter sind ebenfalls in der Klasse "*Einrichtung*" enthalten! Und natürllich auch public!
Also so würden die Methoden nun stimmen?

Methode1: (zum ändern des Status)

```
public void aendereStatusAtEinrichtung(Einrichtung.ApaErledigt status)
	{
		
	  Einrichtung.apaErledigt = status;
	  if(status == Einrichtung.ApaErledigt.Erledigt) {
	    Einrichtung.setStatus(Status.Erledigt);
	  }
	}
```


Methode2: (zum Überprüfen, ob es erledigt wurde)

```
@Transactional 
	public boolean isEinrichtungErledigt()
	{
		
		Einrichtung.ApaErledigt apaErledigt;
		if(apaErledigt == Einrichtung.ApaErledigt.Erledigt)
		{
			return true;
		}
		
		return false;
	}
```


----------



## tfa (4. Sep 2009)

Ich meinte das:


```
public boolean istApaErledigt(){
  return apaErledigt == Einrichtung.ApaErledigt.Erledigt;
}
```

ist besser als das:


```
public boolean isApaErledigtErledigt()
    {
        if(apaErledigt == Einrichtung.ApaErledigt.Erledigt)
        {
            return true;
        }
        
        return false;
    }
```

In deiner Version legst du übrigens eine nicht-initialisierte lokale Variable an, mit der du vergleichst.  Das funktioniert nicht.


----------



## Spacerat (4. Sep 2009)

apaErledigt und status sind Instanzvariablen und die Methoden Instanzmethoden von Einrichtung. Das bedeutet, das die Klasse Service auf jeden Fall eine Instanz von Einrichtung benötigt, um dessen Methoden aufzurufen. So wie du das machst, müssten alle Methoden und Variablen von Einrichtung statisch sein. Aber statische Getter und Setter? Ich weis nicht... Einrichtung könnte dann genau so gut eine Implementierung des Unwortes mit dem S. werden. Eine relativ korrekte Implementation des ganzen würde so aussehen.
	
	
	
	





```
public class Einrichtung
{
  public enum ApaErledigt {
    ERLEDIGT,
    OFFEN
  }

  public enum Status {
    ERLEDIGT,
    OFFEN
  }

  private Status status = Status.OFFEN;
  private ApaErledigt apaErledigt = ApaErledigt.OFFEN;

  public void setApaErledigt(ApaErledigt apaErledigt)
  {
    if(apaErledigt != null) {
      this.apaErledigt = apaErledigt;
      if(apaErledigt == ApaErledigt.ERLEDIGT) {
        setStatus(Status.Erledigt);
      }
    }
  }

  public void setStatus(Status status)
  {
    if(status != null) {
      this.status = status;
    }
  }

  public Status getStatus()
  {
    return status;
  }

  public ApaErledigt getApaErledigt()
  {
    return apaErledigt;
  }

  public boolean istApaErledigt()
  {
    return apaErledigt == ApaErledigt.ERLEDIGT;
  }

  public boolean istErledigt()
  {
    return status == Status.ERLEDIGT;
  }
}
```


----------



## tfa (4. Sep 2009)

> ```
> public void setStatus(Status status)
> {
> if(status != null) {
> ...


Und was soll bei 
	
	
	
	





```
null
```
passieren? Gar nichts?

Lieber so:


```
public void setStatus(Status status)
  {
    if(status != null) {
      this.status = status;
    }
    else {
        throw new NullPointerException("status darf nicht null sein");
    }
  }
```


----------



## Spacerat (4. Sep 2009)

tfa hat gesagt.:


> Und was soll bei
> 
> 
> 
> ...


Absolut korrekt! Warum mit NPEs um sich schmeissen, wenn man diese nirgendwo mehr abfangen sollte? Wenn etwas passieren sollte würde ich eher für so etwas plädieren
	
	
	
	





```
public boolean setStatus(Status status)
  {
    if(status != null) {
      this.status = status;
      return true;
    }
    return false;
  }
```


----------



## tfa (4. Sep 2009)

Spacerat hat gesagt.:


> Absolut korrekt! Warum mit NPEs um sich schmeissen, wenn man diese nirgendwo mehr abfangen sollte?


Völlig falsch. Der Status darf nie null sein. Wenn doch, ist das ein Fehler, der durch die Exception angezeigt wird. Diese Exception wird natürlich nicht behandelt! In einem fehlerfreien Programm wird sie nicht auftreten. Wenn's dir lieber ist, wirf eine IllegalArgumentException.



Spacerat hat gesagt.:


> Wenn etwas passieren sollte würde ich eher für so etwas plädieren
> 
> 
> 
> ...



Was für einen Vorteil soll das haben?


----------



## maki (4. Sep 2009)

Wenn der Vertrag von setStatus besagt dass der zu setzende Status nicht null sein darf, und dieser Vertrag verletzt wird, dann wäre eine NPE oder IllegalArgumetnException angebracht, returnwerte sind da fehl am Platz.

Abgesehen davon finde ich, dass Methoden mit Seiteneffekten (setter zB.) im allgemeinen keine Rückgabewerte haben sollten.

Nachtrag: tfa war mal wieder schneller


----------



## Spacerat (4. Sep 2009)

> Was für einen Vorteil soll das haben?


z.B. den, das man sich aussuchen kann, ob man eine (Fehler-) Rückmeldung haben will oder nicht und das ohne "try / catch".
@maki: ...und du warst mal wieder so schnell, das ich ein Zitat in meinen Beitrag mogeln musste ;(


----------



## tfa (4. Sep 2009)

Spacerat hat gesagt.:


> z.B. den, das man sich aussuchen kann, ob man eine (Fehler-) Rückmeldung haben will oder nicht und das ohne "try / catch".


Auf null kannst du doch prüfen, bevor du die Methode aufrufst. Und ein try/catch ist bei NullPointerExceptions völlig unnötig.


----------



## maki (4. Sep 2009)

Spacerat hat gesagt.:


> z.B. den, das man sich aussuchen kann, ob man eine (Fehler-) Rückmeldung haben will oder nicht und das ohne "try / catch".


Rückgabewerte verlagern die Verantwortung der Prüfung ob eine Aktion erfolgreich war zum Aufrufer, dieser müsste dann bei jeder Änderung überprüfen ob diese auch wirklich geklappt hat, den Client zu zwingen sowas bei einer Statusänderung zu machen halte ich für daneben.

Ist aber eine alte Diskussion, Rückgabewerte vs. Exceptions, wobei ersteres eher in C bzw. anderen Sprachen angewendet wurde die keine Execptions unterstützt haben.


----------



## Spacerat (4. Sep 2009)

tfa hat gesagt.:


> Und ein try/catch ist bei NullPointerExceptions völlig unnötig.


Das sehe ich in einigen Fällen zwecks Vereinfachung und Lesbarkeit ein klitze was anders  http://www.java-forum.org/allgemeine-java-themen/87667-java-7-auslese-3.html#post552897. Bei der "old-c-style" Methode fällt das allerdings aus. Auf die NPE kann man warten bis der Arzt kommt. Andererseits können die Werte (status und apaErledigt) auch nie null werden, weil null als ungültig erkannt und ignoriert wird.


----------



## rider (4. Sep 2009)

So: (Erst mal sorry, für dieses Hin- und Her)
jetzt habe ich noch ein weiteres Problem:

*ApaErledigt *soll auch nur auf gesetzt werden, wenn überhaupt ein *Arbeitsplatz *angefordert wird.
Für *Arbeitsplatz *habe ich auch ein Enum:

```
public enum Arbeitsplatzausstattung
	{
		JA,
		NEIN		
	}
	@Column(name="arbeitsplatzausstattung",length=4,nullable=false)
	@Enumerated(STRING)
	private Arbeitsplatzausstattung arbeitsplatzausstattung = Arbeitsplatzausstattung.NEIN;
```

Stimmt diese Methode dann so? Oder brauche ich den Arbeitsplatz auch im Parameter?


```
public void setApaErledigt(ApaErledigt apaErledigt)
	  {
	    if(apaErledigt != null) {
	      this.apaErledigt = apaErledigt;
	      if(arbeitsplatzausstattung == Arbeitsplatzausstattung.JA && 
	    	 apaErledigt == ApaErledigt.ERLEDIGT) {
	        setApaErledigt(ApaErledigt .ERLEDIGT);
	      }
	    }
	  }
```


Stimmt das bei dem Setter? Weil der Status soll ja erst dann gesetzt werden, wenn ApaErledigt auf "Erledigt" gesetzt wurde:

```
public boolean setStatus(Status status)
	  {
	    if(status != null) {
	      this.status = status;
	      return true;
	    }
	    return false;
	  }
```


----------



## tfa (4. Sep 2009)

Spacerat hat gesagt.:


> Das sehe ich in einigen Fällen zwecks Vereinfachung und Lesbarkeit ein klitze was anders  http://www.java-forum.org/allgemeine-java-themen/87667-java-7-auslese-3.html#post552897.


Wenn du meinst...
Meiner Meinung nach ist das ein ziemlich katastrophaler Missbrauch von Exceptions. (Mit der 
	
	
	
	





```
?.
```
-Notation wollte man sowas ja gerade verhindern).


----------



## bygones (4. Sep 2009)

rider hat gesagt.:


> würde es auch so gehen?
> "Einrichtung" ist die Klasse in der das Enum ist!
> 
> 
> ...


warum nicht einfach

```
public boolean isApaErledigtErledigt()
	{
		Einrichtung.ApaErledigt apaErledigt;
		return apaErledigt == Einrichtung.ApaErledigt.Erledigt);
	}
```


----------



## tfa (4. Sep 2009)

> warum nicht einfach


Siehe #25


----------



## Spacerat (4. Sep 2009)

tfa hat gesagt.:


> Wenn du meinst...
> Meiner Meinung nach ist das ein ziemlich katastrophaler Missbrauch von Exceptions. (Mit der
> 
> 
> ...


Genau... wegen 
	
	
	
	





```
?.
```
 mein ich... 
	
	
	
	





```
?.
```
 Wäre demnach auch so ein Missbrauch. Und wie bringt man das der Scala-Lobby bei? Aber what shalls. Viele Wege führen nach Rom.
@TS: Es bleibt also jedem Entwickler selbst überlassen, wie er seine Methoden konditioniert. Ob nun also "old-c-style" oder Exception. Was aber gerade auffällt, ist die Tatsache, das deine Enums durchweg nur zwei Werte haben. Da wäre es angebrachter, zu Gunsten des geringeren Speicherverbrauchs booleans zu verwenden.


----------



## rider (4. Sep 2009)

bygones hat gesagt.:


> warum nicht einfach
> 
> ```
> public boolean isApaErledigtErledigt()
> ...



gibt er mir dann auch "true" oder "false" zurück?


----------



## bygones (4. Sep 2009)

er gibt immer das zurueck was [c]apaErledigt == Einrichtung.ApaErledigt.Erledigt;[/c] ergibt... true oder false


----------



## rider (4. Sep 2009)

Okay, das wusste ich nicht.
Aber: in der Methode isApaErledigtErledigt():
brauche ich da keine IF - Abfrage?

Denn es soll ja nur Erledigt sein, wenn auch *Arbeitsplatzausstattung * "JA" ist. 
Weil es kann ja nicht als Erledigt angegeben sein, wenn Arbeitsplatzausstattung überhaupt nicht angegeben wurde (also auf NEIN ist)


----------



## bygones (4. Sep 2009)

sorry das fachliche versteh ich gar nicht... 

ich habe nur ein beliebtes Konstrukt aufgeloest:

```
if ( BEDINGUNG ) {
 return true;
}
return false;
```
kann man immer zusammenfassen zu

```
return BEDINGUNG
```


----------



## rider (4. Sep 2009)

Okay! Wusste ich nicht, dass das so geht :-/ Danke!

Nun der Reihe nach:
Die Methode *isApaErledigtErledigt():*
Sie soll nur dann TRUE zurückliefern, wenn:

- das ENUM Arbeitsplatzausstattung "JA" liefert
- das ENUM ApaErledigt "ERLEDIGT" liefert


Laut deinem vorherigen Beitrag würde das so aussehen: Stimmt das?

```
public boolean isApaErledigtErledigt()
    {
        return (arbeitsplatzausstattung == Einrichtung.Arbeitsplatzausstattung.JA &&
apaErledigt == Einrichtung.ApaErledigt.ERLEDIGT);
    }
```


----------



## Leroy42 (4. Sep 2009)

Ja!

Obwohl ich den Methodennamen *isApaErledigtErledigt*
schon für etwas seltsam halte.


----------

