enum oder static final boolean?

[-frank]

ich schreibe öfters zwei sehr ähnliche methoden, die nur einen kleinen unterschied aufweisen. (gehts da nur mir so?)
ein (fiktives) beispiel wären zwei methoden, die zahlen ausgeben und zwar entweder aufwärtszählend oder abwärtszählend:

public void countDown(int initialValue) {
//vorarbeit
// zähle runter
//gib zahl aus
//eventuell noch was zu tun
}

public void countUp(int initialValue) {
//vorarbeit
// zähle rauf
//gib zahl aus
//eventuell noch was zu tun
}

in so nem fall mache ich dann ne neue methode:

public void countUpOrDown(int initialValue, boolean countMode) {
//vorarbeit
// je nach countmode zähle rauf oder runter
//gib zahl aus
//eventuell noch was zu tun
}

die beiden anderen methoden lasse ich eventuell noch bestehen, sie rufen dann aber nur noch die 3. methode auf mit dem entsprechenden countMode.

würdet ihr in so ner situation eher

a) es genauso machen und dann zb folgende klassenvariablen deklarieren:

public static final COUNT_UP = true;
public static final COUNT_DOWN = false;

oder b) es mit mit enum machen:

public enum CountMode {COUNT_UP, COUNT_DOWN}

oder c) versuchen Methode und Parameter so zu benennen, dass es eindeutig ist, welcher Mode true und welcher false ist:

public void count(int initialValue, boolean countUp) {..}
public void countUpOrDown(int initialValue, boolean countUp) {..}

wenn es sich schon aus dem namen ergibt, was true und was false bedeutet, also zb bei object.setEditable(boolean editable), dann finde ich diese lösung am besten. in meinem beispiel muss man sich aber zumindest ansehen, wie der parametername lautet (countUp).
variante B bietet sich IMO an, wenn man nicht weiß, wieviele möglichkeiten es in zukunft geben könnte. also zb wenn man goUp() und goDown() hätte und in Zukunft auch goLeft() und goRight() dazukommen könnten, dann würde ich es mit der Methode go(Direction direction) und enum Direction{UP, DOWN, LEFT, RIGHT} versuchen.
bei genau zwei Möglichkeiten wähle ich aber variante A.

wollte nun wissen, wie ihr es macht bzw. wie ihr es gerne vorfinden würdet in nem fremden code, was ihr als lesbarer / leichter verständlich anseht.

danke,
frank

 

[Ark]

Wenn es wirklich nur zwei Richtungen gibt, würde ich das etwa so machen:

public void count(int initialValue, boolean down){
    …
    counter += down ? -1:1;
    …
}

Wenn es jedoch mehrere Richtungen bzw. mehrere Achsen gibt, würde ich das ungefähr so notieren:

public void count(int x, int y, int z, int dx, int dy, int dz){
    …
    xcounter += dx;
    ycounter += dy;
    zcounter += dz;
    …
}

MfG
Ark

 

[Chris_1980]

Also ich benutz enums nur wenn ich ihnen noch n paar eigenschaften mehr anhänge. Für solche Sachen habe ich bisher eigentlich immer nur ints benutzt. Da kann man dann mit den statischen Variablen nen wundbar übersichtlichen SwitchCase bauen, in der art hier:

	public void initMenu(int menu)
	{
		this.menu = menu;
		markerPos = 0;
		holder[0].setBackground(markerColor);
		
		switch(menu)
		{			
			case PLAYER_MENU:
                                               tu.irgendwas();
			break;		
				
			case MODE_MENU:	

			break;
			
			case OPTION_MENU:
                                               tu.irgendwas();
			break;
			
			case SCREENMODE_MENU:	
                                               tu.irgendwas();
			break;
			
			case SOUND_MENU:	
                                               tu.irgendwas();
			break;
			
			case TYPE_MENU:	
                                               tu.irgendwas();
			break;
		}		

                        tu.irgendwas.was.für.alle.Fälle.relavant.ist();	

	}

aber prinzipiell find ich alle genannten möglichkeiten gut.


MFG, Chris

 

[Marco13]

Solche "ähnlichen Methoden" sollte man grundsätzlich vermeiden. (Wenn man mit ZIP eine Java-Datei um mehr als 5% verkleinern kann, ist die Code-Entropie noch nicht hoch genug :wink: )

Ich finde die Java-Enums ja toll. Sie sind vor allem SEHR mächtig. Und man kann sie AUCH für switch/case verwenden, deswegen gibt es KAUM noch einen Grund, da public static final ints zu verwenden:

public enum CountMode {COUNT_UP, COUNT_DOWN} 

public void count(CountMode mode)
{
    switch (mode)
    {
        case COUNT_UP: counter++; break;
        case COUNT_DOWN: counter--; break;
    }
}

So ist das "normal", aber eigentlich ziemlich un-Objektorientiert. Wie wär's mit sowas

public enum CountMode 
{    
    COUNT_UP(1), 
    COUNT_DOWN(-1);

    private int stepSize = 0;

    public CountMode(int step)
    {
        this.stepSize = step;
    }
    public int getStepSize()
    {
        return stepSize;
    }
} 

public void count(CountMode mode)
{
    counter += mode.getStepSize();
}

Dann kann man ganz leicht weitere Modi hinzufügen

public enum CountMode 
{    
    COUNT_UP(1), 
    COUNT_DOWN(-1);
    COUNT_DOWN_FAST(-10);
...
}

(man könnte das ewig weiterspinnen und weiter verallgemeinern....)


Ich finde jedenfalls, dass man statt public static final int FAST immer enum verwenden kann...

 

[-frank]

danke mal an euch alle. WENN es mehr als zwei möglichkeiten gibt, dann nehm ich auch auf jeden fall enum, keine frage. auch wenn ich mehr funktionalität drin brauche.

@marco13:

das mein beispiel un-objektorniert ist mir bewusst. ich wollte auf situationen hinaus, wo es wirklich nur auf ein if hinausläuft, zb bei ner GUI-Klasse:

void showInfo(String info, boolean leftOrRight) {
    // vorarbeit
    ...
    if(leftOrRight == LEFT) {
        leftLabel.setText(info);
    } else {
        rightLabel.setText(info);
    }

    // nacharbeit
    ..
}

ich weiß nicht, ob es üblich ist, aber ich habe oft solche fälle. zb auch wenn ich ein objekt entweder hinzufügen oder entfernen muss. da kann es durchaus sein, dass ich vorher auf bestimmte bedingungen warten und nacher einige aktualisierungen vornehmen muss. folglich hätte ich in den add/remove-methoden code-duplikate oder ich müsste im aufrufenden objekt mehr methoden aufrufen:

obj.prepare();
obj.add(otherobj); oder obj.remove(otherobj);
obj.update();

oder ich schreibe den aufruf von prepare/update sowohl in die add als auch die remove methode. dann sind nur noch die aufrufe doppelt, aber es ist immer noch überflüssiger code IMO. --> diese "ähnlichen" methoden umgehe ich doch gerade dadurch, dass ich nen boolean/enum parameter übergebe, oder?

also seh ich das richtig, dass WENN es niemals mehr als zwei möglichkeiten gibt und ich nicht mehr funktionalität brauche, ich genauso gut public static boolean verwenden kann, da das ja quasi einem enum BooleanEnum{TRUE, FLASE} gleichkommt. da so ein einfaches enum objekt aber wohl kaum sehr viel performance fressen wird und man für alle komplexeren entscheidungen (also mehr als 2 möglichkeiten und/oder mehr funktionalität durch erweitertes enum objekt) enum verwenden wird, soll ich auch für diese situation enum verwenden, einfach weils nicht schaden wird, richtig?

 

[Chris_1980]

... Ich finde die Java-Enums ja toll ... Und man kann sie AUCH für switch/case verwenden ...

Das das geht hab ich garnicht gewußt. Das macht sie auf jedenfall noch um einiges atraktiver. :toll:

 

[-frank]

im gegensatz zu ner reihe von int-Zahlen sieht man dann sogar ganz gut, wenn man nen case vergessen hat.

---

noch ein anderes beispiel: boolean als return value (zb Fehler oder Okay). wie siehts hier aus?
schreibt ihr nur

if(!method()) {
    //fehlerbehandlung
}

ich bevorzuge dann doch:
if(method() == ERROR) {
    // fehlerbehandlung
}

(natürlich gibts hier viele fälle, wo ne void methode, die dafür im fehlerfall ne exception wirft, besser ist. aber wenn es so gemacht wird, definiert ihr dann auch hierfür ne enum?

 

[Marco13]

Die Frage, ob man zwei Funktionen macht, oder eine, die ein boolean übergeben bekommt, hängt imho auch stark von der Semantik ab. Sowas wie

void doSomethingAndTheParameterSaysWhatItDoes(boolean add)
{
    ...
    if (add) add();
    else remove();
   ...
}

ist imho SEHR unschön (und gefährlich).

Aber eine Funktion

void doSomething(boolean storeBackupCopy)
{
    ...
    if (storeBackupCopy) storeBackupCopy();
    else { /* do nothing */ }
   ...
}

oder

void doSomething(EnumTyp target)
{
    ...
    switch (target)
    {
        case A: sendDataToSocket(); break; // nur ein Beispiel
        case B: sendDataToFile(); break;
        case C: sendDataToPrinter(); break;
       ...
    }
   ...
}

ist vollkommen legitim.

Bei deinem Beispiel: Wenn vor und nach der Stelle, an der sich die Methoden unterscheiden, "viel" zu tun ist, sollte man das IMHO eben (wenn möglich) genau in solche prepare/update Funktionen packen damit man zwei getrennte Funktionen machen kann

void add()
{
    obj.prepare();
    obj.add(otherobj); 
    obj.update(); 
}
void remove()
{
    obj.prepare();
    obj.remove(otherobj);
    obj.update(); 
}

Die Gemeinsamkeiten sind durch prepare und update "weg-gekapselt", und abgesehen davon MACHEN die Funktionen etwas vollkommen unterschiedeliches - das NUR durch einen boolean-Parameter zu entscheiden fände ich persönlich eher fragwürdig...

 

[-frank]

... ist imho SEHR unschön (und gefährlich).

inwiefern ist es "gefährlich" bzw. was genau meinst du damit?

.. MACHEN die Funktionen etwas vollkommen unterschiedeliches - das NUR durch einen boolean-Parameter zu entscheiden fände ich persönlich eher fragwürdig...

ich verstehe schon, was du meinst. MethodenNamen wie doThisOrThat(boolean thisOrThat) sind natürlich nicht gerade schön. allerdings kann man diese methoden dann ja auch private machen. sichtbar wären dann doThis() und doThat(). die unschöne methode ist somit nur für jemanden relevant, der sich den quellcode ansieht. allerdings gehts mir schon auch darum wie es für jemanden ist, der sich den code durchsieht. und du würdest es ja schonaml nicht so machen...

vermutlich ist die methode mit prepare/update doch besser. wenn man diese beiden methoden aber wirklich nur in doThis() und doThat() braucht (und ich das vorher schon sicher wusste), hab ichs bisher selten so gemacht.

was aber das argument angeht, dass die die zwei funktionen etwas vollkommen unterschiedliches machen:
ist das nicht nur frage des methodennamens?
ich meine, bei list.addOrRemove(Object obj, boolean addOrRemove) bedeuten die wörter natürlich genau das gegenteil von einander. heißt die Methode aber zB list.modify(Object obj, boolean mode) klingt es schon viel ähnlicher. beides ist eine Modifikation an der Liste mithilfe eines Objekts. nur die Art der modifikation wird per parameter angegeben.
macht das für dich nen unterschied oder sagst du, dass es genauso schlecht ist? (ich finds ja anders formuliert schon ein stück besser, wobei vermutlich trotzdem 2 verschiedene Methoden besser geeignet sind)

 

[Lim_Dul]

Meines Erachtens, sollte man versuchen, folgende Kriterien zu erfüllen:

a) Eine Methode macht genau Sache
b) Wenn man die Methodendeklaration liest, sollte klar sein, was die Methode macht, spätestens aber nach dem lesen des JavaDoc Kommentars.

Das ganze unabhängig davon, ob die Methode public, private oder sonstwas ist. Denn es kann gut sein, das entweder fremde Leute mitarbeiten sollen oder, was in privaten Ein-Mann Projekten auch auftritt, dass man mal ein Projekt ruhen lässt und beispielsweise ein halbes Jahr später erst wieder weitermacht. Und in dem Augenblick sind cryptische private Methoden auch schädlich.

Von daher sollte nicht die Frage lauten, was für die auf jeden Fall lesbarere Variante (wie beispielsweise add() und remove()) spricht, sondern warum man den modifyList(boolean mode) bevorzugen sollte.

Man sollte sich immer Gedanken, wie beschreibe ich, was die Methode tut. Und sobald die Beschreibung zu lang ist oder zuviele "Wenn der Paramter A den Wert X hat, dann" vorkommen, dann sieht es danach aus, als wäre die Methode nicht wirklich gut designt und man sollte sich zumindest mal Gedanken machen.

 

[-frank]

Von daher sollte nicht die Frage lauten, was für die auf jeden Fall lesbarere Variante (wie beispielsweise add() und remove()) spricht, sondern warum man den modifyList(boolean mode) bevorzugen sollte.

naja, der grund, warum ich überhaupt auf die idee gekommen bin, den weniger lesbaren weg zu gehen, war eben ein anderer wichtiger vorsatz, nämlich redundaten code zu vermeiden:

add(Object obj) {
    if(check(obj) == INVALID) {
        print("Object ungueltig...");
        return;
    }     
    print("Liste vor dem Hinzufügen" + list);
    synchronized(synchObj) {
        list.add(obj);
    }
    print("Liste nach dem Hinzufügen" + list);
    someObject.updateListInfo(list.size());
}

remove(Object obj) {
    if(check(obj) == INVALID) {
        print("Object ungueltig...");
        return;
    }     
    print("Liste vor dem Entfernen" + list);
    synchronized(synchObj) {
        list.remove(obj);
    }
    print("Liste nach dem Entfernen" + list);
    someObject.updateListInfo(list.size());
}

oder doch so:

modify(Object obj, boolean mode) {
    if(check(obj) == INVALID) {
        print("Object ungueltig...");
        return;
    }     
    print("Liste vor der Modifikation (mode: " + mode + " )" + list);
    synchronized(synchObj) {
        if(mode == TRUE) list.add(obj);
        else list.remove(obj);
    }
    print("Liste nach der Modifikation (mode: " + mode + " )" " + list);
    someObject.updateListInfo(list.size());
}

(in letzterem fall wäre ein enum Mode wieder besser, weil man dann in den beiden printzeilen schön den namen des modes ausgeben könnte und nicht nur true oder false.)

also mir ist da ganz eindeutig variante B lieber. klar sagen die Bezeichnungen remove und add mehr aus, aber wenn ich selber an dem code arbeite und ihn verändern muss, stören die mich die redundanzen wohl weit mehr.

...Und in dem Augenblick sind cryptische private Methoden auch schädlich

da stimme ich dir absolut zu. ich kenne das, wenn man sich im eigenen code nicht mehr auskennt nach einigen monaten. gut gewählte variablen und methoden namen wirken da wunder (+ kommentare). unterschied zwischen public und private methoden gibts IMO aber auch in diesem fall nen großen, nämlich, dass ich im fall 'private' sofort sehe, wo die methode aufgerufen wird. wenn man auf einen blick sieht, wieoft/wo/wie die methode aufgerufen wird, trägt das IMO schon sehr zum verständnis bei, weshalb ich generell schon eher in kauf nehme, wenn ne private method mal weniger verständlich formuliert wird als wenn dies bei ner public methode der fall ist.

 

[Lim_Dul]

In solchen Fällen würde ich aber versuchen, den redundanten Code auszulagern, dass du also nur noch aufrufst:

// ADD:
add(Object obj) {
  if (isInvalid(obj)) return;
  printStatus("before", "add", list);
  // Code für ADD
  printStatus("after", "add", list);
}

remove(Object obj) {
  if (isInvalid(obj)) return;
  printStatus("before", "remove", list);
  // Code für ADD
  printStatus("after", "remove", list);
}

Wobei das natürlich auch immer eine Einzelfallentscheidung ist. Wenn sich die Methoden tatsächlich nur in einer Zeile unterscheiden, spart man so auch nicht viel.

Letzendlich gibt es aber bei der Signatur modify(Object obj, boolean mode) noch ein anderes Problem, und zwar das boolean wirklich zweckentfremdet wird. Mit einem enum wird das ganze dann wieder lesbar.

Ich persönlich tendiere dazu lieber mehr und kleinere Methoden, als allumfassende Methoden. Das Problem bei diesem Beispiel ist, dass sich beide Varianten (zwei Methoden oder eine mit enum) nicht viel nehmen. Ich persönlich würde lieber die zwei Methoden bevorzugen, allerdings ist der Gewinn dabei nicht wirklich groß.

Interessant wird es, wenn die Methoden umfangreicher werden und die Operationen verschiedener und weniger miteinander zu tun haben. Solange man sich aber über die Alternativen bewusst ist und sich explizit für seine Variante entscheidet, auch wenn sie von anderen als etwas schlechter empfunden wird, ist das nicht so schlimm (Sofern man keinen völligen Murks nimmt ). Dann hat man sich zumindest explizit Gedanken gemacht, was bei solchen Design Fragen imminent wichtig ist.

Die meisten Design-Fehler entstehen ja nicht, weil man bewusst ein Design nimmt, obwohl man die anderen, teilweise besseren Alternativen kennt und sich um die Gedanken gemacht hat, sondern weil man sich eben keine oder wenig Gedanken gemacht hat.

 

[-frank]

Die meisten Design-Fehler entstehen ja nicht, weil man bewusst ein Design nimmt, obwohl man die anderen, teilweise besseren Alternativen kennt und sich um die Gedanken gemacht hat, sondern weil man sich eben keine oder wenig Gedanken gemacht hat.

denke du hast recht. wenn man über sowas nachdenkt und sich dann entscheidet, dann sollte das resultat in der regel okay sein. wenn man sich nicht gleich entscheiden konnte, dann lags wohl daran, dass beide varianten vor und nachteile hatten.
allerdings frage ich ja grade deswegen hier nach, denn es hätte ja genauso sein, dass mir hier jemand sagt "100% variante x, weil ...". (man weiß es ja nie ...)

---

um nochmal auf enum zurückzukommen. ein nachteil ist, dass hier nicht erkannt wird, wenn man alle (=beide) enum Werte behandelt hat:

public Object sampleMethod(BooleanEnum booleanEnum) { 
switch(booleanEnum) {
    case TRUE:
        return new Object();
    case FALSE:
        return new Object();
    }
}
}

hier beschwert sich eclipse bei mir, dass die methode ja ein result vom type Object returnieren muss. im fall von

if(boolean) return new Object();
 else return new Object();

wird dies schon erkannt.

bei enum gehts dann halt so:

public Object sampleMethod(BooleanEnum booleanEnum) { 
switch(booleanEnum) {
    case TRUE:
        return new Object();
    case FALSE:
    default:
        return new Object();
    }
}
}

oder so:

public Object sampleMethod(BooleanEnum booleanEnum) { 
switch(booleanEnum) {
    case TRUE:
        return new Object();
    case FALSE:
        return new Object();
    }
}
// unerreichbarer code
return null;
}

wobei variante 1 wohl gefährlich ist, wenn man nicht wirklich 100% weiß, dass niemals ne 3. möglichkeit dazukommen kann.

ein weiterer vorteil von boolean ist IMO, dass man mit !variable sofort den anderen boolean wert bekommt. dafür braucht es bei enum ne zusätzliche methode.
allerdings sind die switch-anweisungen dafür schon schöner lesbar IMO.

 

[Lim_Dul]

Du kannst dir bei eclipse eine Warnung ausgeben lassen, wenn nicht alle Enums behandelt werden im Switch/Case.

Wenn klar ist, dass es explizit bei zwei Möglichkeiten bleibt, geht eventuell ein boolean, allerdings sollte der Paramater dann auch entsprechend benannt sein, dass klar ist, was true und was false bedeutet. Bei add/remove wird das halt schwer

 

[-frank]

Du kannst dir bei eclipse eine Warnung ausgeben lassen, wenn nicht alle Enums behandelt werden im Switch/Case.

ja, das ist auch ziemlich praktisch finde ich. nur WENN ich alle fälle behandelt habe , dann wäre es nett, wenn eclipse unreachable code erkennen würde oder zb nicht mehr melden würde, dass eine variable eventuell null ist. bei if/else-konstrukten wird sowas erkannt. bei einer alle möglichkeiten behandelnden switch anweisung könnte eclipse das doch auch erkennen oder spricht da was dagegen?

 

[Marco13]

Nur mal nebenbei: Bei einem ECHT booleschen Wert ist ein switch eigentlich ziemlich sinnfrei :roll:

if (a==b) return true;
else if (a!=b) return false;
else throw UnknownBooleanStateException();

:wink:

 

[-frank]

Nur mal nebenbei: Bei einem ECHT booleschen Wert ist ein switch eigentlich ziemlich sinnfrei :roll:

if (a==b) return true;
else if (a!=b) return false;
else throw UnknownBooleanStateException();

:wink:

naja, das ist eigentlich das einzige, was mich jetzt noch wirklich dran stört (hab mein aktuelles programm mal umgeschrieben) bei enum. da hab ich dann entweder nach dem switch oder halt im default case codezeilen wie

print("ungültiger wert! " + value);
return null;

obwohl ich weiß, dass der code unreachable ist.
natürlich ist das ganze, wenn man die enum klasse erweitert, sehr angenehm. aber wenns ne "boolsche" enum bleiben soll ist es bissl seltsam finde ich.

 

[Lim_Dul]

Der Code schadet ja nicht.

Generell ist es nicht schlimm, wenn man mehr Code hat. Ganz im Gegenteil ist es meistens eher schädlich, wenn man versucht möglichst wenig Zeilen zu haben.

Lieber für ein sauberer Konzept mehr Zeilen schreiben, auch wenn wie in diesem Fall garantiert ist, dass die nicht aufgerufen werden, als ein nicht ganz so sauberes Konzept.

 

[rik0]

Zur Sicherheit könntest Du ja in den default-case beim switch mit enums ne assertion einbauen...

assert (false) : "Wenn Du das hier liest, fehlt ein case :-)";