Java-svitsjerklæring

Litt teori om Java Switch

Tenk deg at du er en ridder stoppet ved et veiskille. Hvis du går til venstre, vil du miste hesten din. Går du rett, får du kunnskap. Hvordan vil vi representere denne situasjonen i kode? Du vet sikkert allerede at vi bruker konstruksjoner som if-then og if-then-else for å ta disse avgjørelsene.

if (turn_left) { 
    System.out.println("You will lose your horse"); 
}
if (turn_right) {
    System.out.println("You will gain knowledge");
}
else 
    System.out.println("So you're just going to stand there?");

Men hva om veien deler seg ikke i to, men i ti? Du har veier som er "helt til høyre", "litt til venstre for det", "litt mer til venstre" og så videre, totalt 10 mulige veier? Tenk deg hvordan "hvis-så-anne "-koden din vil vokse i denne versjonen!

if (option1)
{…}
else if (option2)
{…}
…
else if (optionN) ...

Anta at du har en 10-veis gaffel i veien (det er viktig her at antallet alternativer er begrenset). For slike situasjoner har Java switch- setningen.

       switch (ExpressionForMakingAChoice) {
           case (Value1):
               Code1;
               break;
           case (Value2):
               Code2;
               break;
...
           case (ValueN):
               CodeN;
               break;
           default:
               CodeForDefaultChoice;
               break;
       }

Slik fungerer utsagnet:

• ExpressionForMakingAChoice blir evaluert. Deretter sammenligner switch-setningen den resulterende verdien med neste ValueX (i den rekkefølgen de er oppført).
• Hvis ExpressionForMakingAChoice samsvarer med ValueX, blir koden etter kolon utført.
• Hvis det oppstår en break -setning, overføres kontrollen utenfor switch-setningen.
• Hvis ExpressionForMakingAChoice ikke samsvarer med noen ValueX, overføres kontrollen til CodeForDefaultCase.

Viktige poeng

• I switch-setningen må typen ExpressionForMakingAChoice være en av følgende:

  • byte , kort , char , int .
  • Byte , Short , Character , Heltall (omslag av de primitive datatypene).
  • String .
  • Enum .
• Standardblokken er valgfri . Hvis den er fraværende og ExpressionForMakingAChoice ikke samsvarer med noen ValueX, vil ingen handling bli utført.
• Pauseerklæringen er ikke nødvendig . Hvis den er fraværende, vil koden fortsette å bli utført (ignorerer ytterligere sammenligninger i case-setningene) til den første forekomsten av break eller til slutten av switch- setningen.
• Hvis den samme koden må kjøres for flere valg, kan vi eliminere duplisering ved å spesifisere flere påfølgende case -setninger.

La oss nå ta en titt på hvordan switch-setningen brukes i Java

Ikke bekymre deg: vi er ferdige med teorien. Etter at du har sett følgende eksempler, vil alt bli mye klarere. Vel, la oss komme i gang. La oss se på et eksempel fra astronomi som involverer planetene i solsystemet vårt. I samsvar med de siste internasjonale holdningene har vi ekskludert Pluto (på grunn av egenskapene til dens bane). Vi husker at planetene våre er ordnet etter deres avstand fra solen som følger: Merkur, Venus, Jorden, Mars, Jupiter, Saturn, Uranus og Neptun. La oss skrive en Java-metode som tar en planets ordenstall (i forhold til dens avstand fra solen) og returnerer hovedkomponentene i planetens atmosfære som en List<String>. Du vil huske at noen planeter har en lignende atmosfærisk sammensetning. Dermed inneholder Venus og Mars hovedsakelig karbondioksid; atmosfæren til Jupiter og Saturn består av hydrogen og helium; og Uranus og Neptun tilsetter metan til det siste paret gasser. Her er funksjonen vår:

public static List<String> getPlanetAtmosphere(int seqNumberFromSun) {
    List<String> result = new ArrayList<>();
    switch (seqNumberFromSun) {
        case 1: result.add("No atmosphere");
            break;
        case 2:
        case 4: result.add("Carbon dioxide");
            break;
        case 3: result.add("Carbon dioxide");
            result.add("Nitrogen");
            result.add ("Oxygen");
            break;
        case 5:
        case 6: result.add("Hydrogen");
            result.add("Helium");
            break;
        case 7:
        case 8: result.add("Methane");
            result.add("Hydrogen");
            result.add("Helium");
            break;
        default:
            break;
    }
    return result;
}

Merk at vi bruker den samme koden for planeter med identiske atmosfæriske sammensetninger. Dette gjorde vi ved å bruke fortløpende saksuttalelser . Hvis vi ønsker å få sammensetningen av atmosfæren til hjemmeplaneten vår, kaller vi metoden vår med 3 som argument:

getPlanetAtmosphere(3).
System.out.println(getPlanetAtmosphere(3)) returns ["Carbon dioxide", "Nitrogen", "Oxygen"].

Eksperimenter med brudd: Hva skjer hvis vi fjerner alle bruddsetningene ? La oss gi det en sjanse:

    public static List<String> getPlanetAtmosphere(int seqNumberFromSun) {
        List<String> result = new ArrayList<>();
        switch (seqNumberFromSun) {
            case 1: result.add("No atmosphere");
            case 2:
            case 4: result.add("Carbon dioxide");
            case 3: result.add("Carbon dioxide");
                result.add("Nitrogen");
                result.add ("Oxygen");
            case 5:
            case 6: result.add("Hydrogen");
                result.add("Helium");
            case 7:
            case 8: result.add("Methane");
                result.add("Hydrogen");
                result.add("Helium");
            default:
        }
        return result;
    }

Hvis vi skriver ut resultatet av System.out.println(getPlanetAtmosphere(3)) , så finner vi at hjemmeplaneten vår ikke er så levelig. Eller er det? Døm selv: ["karbondioksid", "nitrogen", "oksygen", "hydrogen", "helium", "metan", "hydrogen", "helium"] . Hvorfor skjedde dette? Programmet utfører alle kasussetningene etter den første matchingen til slutten av bryterblokken .

Overdreven optimalisering av bruddutsagn

Merk at vi kan forbedre metoden ved å ordne bruddutsagn og tilfeller annerledes.

public static List<String> getPlanetAtmosphere(int seqNumberFromSun) {
    List<String> result = new ArrayList<>();
    switch (seqNumberFromSun) {
        case 1: result.add("No atmosphere");
                break;
        case 3: result.add("Nitrogen");
                result.add ("Oxygen");
        case 2:
        case 4: result.add("Carbon dioxide");
                break;
        case 7:
        case 8: result.add("Methane");
        case 5:
        case 6: result.add("Hydrogen");
                result.add("Helium");
    }
     return result;
}

Ser ut som mindre kode, ikke sant? Vi har redusert det totale antallet uttalelser ved å leke med rekkefølgen på saksuttalelsene og omgruppere dem. Nå legges hver type gass til listen i bare én kodelinje. Koden gitt i det siste eksemplet er kun for å vise hvordan ting fungerer. Vi anbefaler ikke å skrive kode på denne måten. Hvis forfatteren av slik Java-kode (for ikke å snakke om andre programmerere) må vedlikeholde den, vil han eller hun finne det svært vanskelig å rekonstruere logikken bak dannelsen av disse kasusblokkene og koden som utføres i switch- setningen .

Forskjeller fra if

Gitt de ytre likhetene til if- og switch- setninger, ikke glem at switch- setningen velger en av tilfellene basert på en SPESIFIK VERDI, mens if-setningen kan ha et hvilket som helst boolsk uttrykk. Ha dette i bakhodet når du designer koden din.

Konklusjon

• Bruk case -setningen for mer enn to grener for ikke å fylle koden med if-setninger.
• Ikke glem å fullføre den logiske blokken til grenen for hver spesifikk verdi (case-setning) ved å sette inn en break -setning.
• Switch - setningens uttrykk kan være en Enum eller String , så vel som noen primitive typer.
• Husk standardblokken . Bruk den til å håndtere uventede verdier.
• For å optimere ytelsen, flytt kodegrenene som tilsvarer de vanligste verdiene til begynnelsen av bryterblokken .
• Ikke la deg rive med i din "optimalisering" ved å slette break- setningene på slutten av saksuttalelsene – slik kode er vanskelig å forstå, og som et resultat vanskelig å vedlikeholde.