[Java] Hoe kan het switch-statement vermeden worden

[Anoniem: 82686]

Ik weet niet of ik deze vraag hier wel mag stellen, omdat er blijkbaar niet veel mag gevraagd worden, voor je topic gesloten wordt.
Ik zou dus willen weten (heb al gezocht in google) hoe je dus het Java-switch-statement kan vermijden. Ik vond enkel via meerdere if'en, maar zou het niet anders kunnen?


Alvast bedankt!

[Janoz]

Wat is het probleem met een switch statement? En wat is er mis met een reeks if's? Uiteindelijk zal het toch worden gecompileerd naar dezelfde functionaliteit..

offtopic:
Het is niet nodig om je in te dekken mbt het niveau van je topic. Het is eerder irritant. Die eerste zin zou je dan ook best weg mogen laten

[ Voor 35% gewijzigd door Janoz op 05-06-2003 17:00 ]

[Donderwolk]

niet dat ik weet. Waarom wil je uberhaupt een switch vermijden???

De andere oplossing is zoals je al zei:

if(){}
else if(){}
else if(){}

etc.

[Anoniem: 45185]

Waarom zou je het anders willen, wat is je toepassing van het switch statement?

[Anoniem: 64569]

Tja, wat is er mis met een switch-statement? Ik vraag me trouwens wel af wat sneller is:

Java:

switch(een_integer)
{
    case DOE_IETS: //1
         blah();
         break;
 
    case DOET_IETS_ANDERS: //2
         blah2();
         break;
 
   //....................

    case DOET_NOG _IETS: //100
         blah100();
         break;
}

of dit:

Java:

if(blah)
{
    blah();
}
else 
if(blah2)
{
   blah2();
}
else
//......
if(blah100)
{
   blah100();
}

Dus ofwel 100 cases of 100 if..else if statements.
Het voordeel van de switch is dat je je integers een naam kan geven zodat het voor jezelf duidelijker leesbaar is (case DOE_IETS bijv)
Zelf heb ik altijd het idee dat een switch sneller is, omdat er gekeken wordt wat de waarde van de 'een_integer' is en dan direct dat uitgevoerd wordt. Terwijl bij de 'if...else if' alle if-statements getest worden...of kraam ik onzin uit. Wil het zelf namelijk wel graag weten

[.oisyn]

Niet elke switch statement is als een reeks if-else-if statements te schrijven.

Een switch definieert bijvoorbeeld geen lokale scope, en bovendien kan er na een case met de volgende worden verder gegaan als het break-statement mist

[.oisyn]

Anoniem: 64569 schreef op 05 June 2003 @ 17:14:
Zelf heb ik altijd het idee dat een switch sneller is, omdat er gekeken wordt wat de waarde van de 'een_integer' is en dan direct dat uitgevoerd wordt. Terwijl bij de 'if...else if' alle if-statements getest worden...of kraam ik onzin uit. Wil het zelf namelijk wel graag weten

Een compiler kan het idd optimalizeren met bijvoorbeeld een lookuptable of een binaire zoekboom. De lookuptable is overigens niet met een if-else-if reeks voor elkaar te krijgen, maar de binaire zoekboom gaat natuurlijk prima.

Bovendien kun je de ifs zo ordenen dat het het efficientst werkt voor je programma, nadat je hebt geanalyzeerd welke opties het meest voorkomen

[Anoniem: 22001]

.oisyn schreef op 05 June 2003 @ 17:16:
en bovendien kan er na een case met de volgende worden verder gegaan als het break-statement mist

In java niet toch?

[.oisyn]

Sinds wanneer niet?

[Janoz]

Wel een beetje onzin . In principe worden beide stukjes source naar hetzelfde gecompileerd. Het switch statement zal immers ook de juiste case moeten zoeken bij de waarde en in de if reeks worden de test alleen gedaan totdat er een true gevonden is.

Het enige verschil is dat een switch door de compiler misschien wat makkelijker te optimaliseren is. Aan de andere kant heeft de if reeks weer het voordeel dat je veel makkelijker op bv ranges kunt testen.

--

Ik ben weer veel te sloom.. Om toch nog wat toe te voegen.... Ook in java heb je een break en die werkt idd net als .oisyn zegt.

[ Voor 14% gewijzigd door Janoz op 05-06-2003 17:22 ]

[Anoniem: 64569]

Dat laatste ben ik met je eens...maar stel nu eens dat elke case of elke if een evengrote kans heeft om voor te komen? Welke zou je dan kiezen?

[.oisyn]

De switch: die is daarvoor gemaakt (en leest ook beter imho)

[ Voor 28% gewijzigd door .oisyn op 05-06-2003 17:23 ]

[Anoniem: 22001]

Janoz schreef op 05 June 2003 @ 17:20:
Ook in java heb je een break en die werkt idd net als .oisyn zegt.

Hmm, er was toch een taal die gen fallthrough had in zijn switch statement, C# misschien dan.

[Erkens]

Anoniem: 64569 schreef op 05 June 2003 @ 17:21:
Dat laatste ben ik met je eens...maar stel nu eens dat elke case of elke if een evengrote kans heeft om voor te komen? Welke zou je dan kiezen?

switch, omdat dat beter te lezen is dan een zooi if-statements

Java:

if (i==1){
  // doe 1
}else if (i==2){
  // doe 2
}else if (i==3){
  // doe 3
}else{
  // doe iets anders
}

of

Java:

switch(i){
 case 1:
   // doe 1
   break;
 case 2:
   // doe 2
   break;
 case 3:
   // doe 3
  break;
 default:
    // doe iets anders
}

je kan wel zeggen dat je code langer wordt met een switch, maar persoonlijk vind ik een swich makkelijker te overzien dan een zooi if statments

[ Voor 11% gewijzigd door Erkens op 05-06-2003 17:28 ]

[Glimi]

Switches met 100 statements zijn ook niet behapbaar met if/else of vice versa. In zo'n geval ga ik eerder denken aan polymorphisme. Neem het volgende stukje

Java:

switch( type ) {

        case User.TYPE_BOSS:
                ..
        case User.TYPE_BIG_BOSS:
                ..
        case User.TYPE_NORMAL:
                ..
}

Dit is op te lossen door voor elk type een klasse te maken en dan dmv polymorphisme de juiste code te laten draaien

Als je ook iets als een fall-through nodig hebt, kan dat heel simpel dmv een super() of een template method
Zie: http://www.refactoring.co...onalWithPolymorphism.html

[ Voor 7% gewijzigd door Glimi op 05-06-2003 17:52 ]

[whoami]

Een switch kan je ook niet altijd gebruiken. Een switch kan je bv niet gebruiken als je strings wilt vergelijken.

Verder kan je in bepaalde gevallen dmv een abstract factory een switch omzeilen. (Wat Glimi ook al zegt mbt dat polymorphisme in die post hier boven mij).

Anoniem: 22001 schreef op 05 juni 2003 @ 17:26:
[...]

Hmm, er was toch een taal die gen fallthrough had in zijn switch statement, C# misschien dan.

In C# is er idd geen fallthrough mogelijk. Hoe dat in Java zit, weet ik niet.

[ Voor 34% gewijzigd door whoami op 05-06-2003 19:05 ]

[hobbit_be]

als je strings moet vergelijken gebruik ik altijd een hash

[Anoniem: 82686]

ok, bedankt voor de antwoorden. Vooral Glimi, daar ga ik me even in verdiepen.
Bedankt!

[VisionMaster]

hobbit_be schreef op 05 June 2003 @ 19:06:
als je strings moet vergelijken gebruik ik altijd een hash

Hoe doe je dat ongeveer?

[hobbit_be]

VisionMaster schreef op 05 June 2003 @ 19:10:
[...]

Hoe doe je dat ongeveer?

zet je hits in een HashMap natuurlijk. Let wel: alleen op een bepaald punt gaat dit sneller zijn , niet voor 2 or 3 compares maar alles boven 10 zet ik toch vaak in een HashMap zodoende word ie ook heel eenvoudig uitbreidbaar en je code wordt er ook ineens veel duidelijker door. Wat je doet na je hit (ie wat steek je in de object van de Hash hangt van jezelf af, maar ik gebruik meestel een Interface pattroon alhoewel ik ook een cached Reflection geval heb, maar dat is nasty )

edit:

Java:

HashMap tMap = new HashMap();
tMap.add("multiply", Multiply.getInstance());...
//met Multiply implements Runnable ofzo
...

Runnable tRun = tMap.get(aString);
if (tRun!=null)
{
    tRun.run();
}

geen gekanker over code correctheid please

edit2:
voor onze XUL (ie XML -> Swing) heb ik zo een 'map' met 87 elements die overeen komen met een element name en die kunnen dan direct gebouwd worden door het Factory pattern. Als ik daar if/else if zou moeten gebruiken is dat ridiculous en ook vele malen trager (ie alleen de source Hash moet worden herberekent)

[ Voor 35% gewijzigd door hobbit_be op 05-06-2003 19:23 ]

[farlane]

Door gebruik te maken van inheritance.

[MSalters]

In theorie kun je een switch net zo optimaliseren als de equivalente if..elseif..else constructie en andersom. In de praktijk is het veel teveel werk voor een compiler om van een lijst if-condities te checken of het als een switch te schrijven is. Het is echter gebruikelijk dat een compiler een switch naar een lijst if..elseif condities vertaalt.

Gebruik dus switch, en laat de compiler de keus.

[JeroenTheStig]

Anoniem: 64569 schreef op 05 June 2003 @ 17:14:
...
Het voordeel van de switch is dat je je integers een naam kan geven zodat het voor jezelf duidelijker leesbaar is (case DOE_IETS bijv)
...

hee interessant, hoe doe je zoiets? Ik wist niet dat dit in Java kon

[curry684]

BoKToR schreef op 07 June 2003 @ 11:50:
hee interessant, hoe doe je zoiets? Ik wist niet dat dit in Java kon

Zoektermen enum en enumerate(s).

[hobbit_be]

curry684 schreef op 07 juni 2003 @ 12:08:
[...]

Zoektermen enum en enumerate(s).

je denkt toch niet dat iemand java 1.5 al aan het gebruiken is ofzo? (behalve mbravenboer).

public static final int DOE_IETS = 0;

[whoami]

curry684 schreef op 07 June 2003 @ 12:08:
[...]

Zoektermen enum en enumerate(s).

Je kan het trouwens ook gewoon doen door constanten te definieren, je hoeft daarvoor niet perse enums gebruiken.
Ik denk trouwens dat voorbeeld in Java niet zal werken met enums....
In Java (en in C# zal je) -vermoed ik- het zo moeten doen als je gebruik maakt van enums:

code:

enum MyEnumType
{
     blaat1,
     blaat2,
     blaat3
}

MyEnumType    anEnum;

anEnum = MyEnumType.blaat2

switch (anEnum)
{
  case MyEnumType.blaat1 : // do something;
                        break;
  case MyEnumType.blaat2 : // do something else
                        break;
  case MyEnumType.blaat2 : // do something different
                         break;
}

Je zal hier die cases niet kunnen vervangen door een bijhorende integer-waarde zoals in C++.

[ Voor 5% gewijzigd door whoami op 07-06-2003 12:24 ]

[hobbit_be]

whoami schreef op 07 June 2003 @ 12:23:
[...]
enum MyEnumType
{
blaat1,
blaat2,
blaat3
}

en nog maar eens: Java 1.4 kent helemaal geen enum...

[whoami]

hobbit_be schreef op 07 June 2003 @ 12:26:
[...]


en nog maar eens: Java 1.4 kent helemaal geen enum...

Nouja, ik ging er vanuit van wel.
(Vandaar dat ik ook C# erin gezet heb, en dat ik er dat zinnetje over die const heb bijgezet. )

Wel zwak van Java....

[ Voor 10% gewijzigd door whoami op 07-06-2003 12:30 ]

[PommeFritz]

hobbit_be schreef op 05 June 2003 @ 19:06:
als je strings moet vergelijken gebruik ik altijd een hash

PAS OP! Ooit van hash-colissions gehoord? Als hash(string1)==hash(string2) is dat geen garantie dat string1 en string2 gelijk aan elkaar zijn!

[hobbit_be]

PommeFritz schreef op 07 juni 2003 @ 14:30:
[...]

PAS OP! Ooit van hash-colissions gehoord? Als hash(string1)==hash(string2) is dat geen garantie dat string1 en string2 gelijk aan elkaar zijn!

Fair enough - maar die kans is heel klein, je zou eventueel een derived van kunnen maken die als de hash hetzelfde is nog eens de string compared to be sure. Hoe noem je zoiets ook alweer? HashTree ofzo? dus:

HashMap
key1, (content is een ArrayList van alle voor die hashmap enzovoorts)
key2,

En dan je keys nog eens Quicksorted steken en weet ik wat en je vliegt... (nou ja, gaat lekker en ook heel uitbreidbaar)