Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
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!
Java:
public void erledigtEinrichtung(){
Einrichtung einrichtung = new Einrichtung();
if (einrichtung.getApaErledigt() == einrichtung.ApaErledigt.Erledigt)
{
einrichtung.setStatus(Status.Erledigt);
}
}
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.
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.
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.
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.
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?
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.
@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...
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.
Java:
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;
}
}
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
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.
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.
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 ;(
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.
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.
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.
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)
