2013-08-22 13 views
5

Czy źle jest mieć obudowę przełącznika w obudowie przełącznika? Jeśli tak, jakie są alternatywy? Naprawdę nie chcę używać if/else if, jeśli nie potrzebuję.Czy źle jest mieć obudowę przełącznika w obudowie przełącznika?

Zamiast robić niektóre jak:

if((this == 1) && (that == 1)){ //something } 
else if((this == 1) && (that == 2)){ //something } 
else if((this == 2) && (that == 3)){ //something } 

Myślałam wzdłuż linii:

switch(this){ 
    case 1: 
     switch(that){ 
      case 1: 
       // something 
      break; 
      .... 
     } 
    break; 
    .... 
} 

To po prostu wygląda naprawdę źle ze mną. Nie jest źle w składni, ale źle pod względem właściwej praktyki.

+2

Widzę przypadki, w których jest OK. Ale wpatrywałam się w to długo i sprawdziłam, czy mogę znaleźć prostszą technikę. –

+0

Nie w rzeczywistości dupe, ale ma istotne/interesujące informacje: http://stackoverflow.com/questions/7807970/nesting-switch-cases-in-javascript-any-speed-advantage – Joum

+1

Aby uzyskać odpowiednie odpowiedzi, lepiej byłoby dodaj swój kod do pytania ... –

Odpowiedz

3

Unikać następujące podejście

switch(id) 
{ 
    case 1: 
    { 
     switch (subid) 
     { 
      case 4: 
       // nested code 
     } 
    } 
    case 2: 
     // some code 
} 

Korzystny podejście i poprawić swój kod przesuwając zagnieżdżony sekcję do metody

switch(id) 
{ 
    case 1: 
     SubSwtich(subid); 
     break; 
    case 2: 
     // some code 
} 

function SubSwtich(int subid) 
{ 
     switch (subid) 
     { 
      case 4: 
       // nested code 
     } 
} 
+0

Dziękuję wszystkim za wspaniałe odpowiedzi. Doceniam cały wgląd. – seroth

3

uważam, że to źle pratice. w większości przypadków jest to nieczytelne.

można wyodrębnić przypadki przełączeń "pod" do metod.

7

Złą praktyką jest posiadanie ogromnych funkcji, które wykonują wiele różnych czynności. Jeśli masz obudowę przełącznika w obudowie przełącznika, sugeruje to, że twoja funkcja jest prawdopodobnie zbyt duża i powinieneś rozważyć podzielenie jej na mniejsze, łatwiejsze do zrozumienia porcje.

Ale nie ma twardych reguł; wszystko zależy od dokładnego scenariusza.

0

Zła praktyka? Nie! Prawdopodobnie potencjalny ból w przypadku rozwiązywania problemów! Zobacz, co możesz zrobić, przekształcając wszystkie "opcje" w coś bardziej zorganizowanego i często połączonego. Może nawet napisać własną funkcję, stosując metodę przeciążania określoną przez liczbę wysyłanych parametrów.

Spójrz na at this SO post i zobacz, czy daje ci to jakieś pomysły.

0

Powinieneś złamać kod w różnych procedurach, w zależności od instrukcji switch, a także w procedurze, w której nadal możesz używać przełącznika. Tak jak podążanie.

private void Switch(int value) 
    { 

     switch (value) 
     { 
      case 1: 
       SwitchNest(value); 
       break; 
      case 2: 
       break; 
     } 
    } 

    private void SwitchNest(int value) 
    { 
     switch (value) 
     { 
      case 1: 
       SwitchOtherMethod(value); 
       break; 
      case 2: 
       break; 
     } 
    } 
+0

Funkcja do jednorazowego użytku, argumentowałbym, nie jest tego warta. Nie wspominając już o tym, że przeskakujesz teraz miejsca w kodzie, by śledzić przepływ pracy zamiast jednego miejsca. (Z punktu widzenia czytelności, a może to być IMHO, wolałbym przesiewać przełączniki zagnieżdżone, niż gonić jednorazowe funkcje.) –

1

Jeśli to sprawia, że ​​Twój kod trudniejsze do odczytania, to jest złe ćwiczyć.

Niezależnie od tego, czy tak jest w danym przykładzie, decyzja należy do Ciebie, ale generalnie powiedziałbym, że prawdopodobnie tak by było.

Pytałeś alternatyw ...

  1. Extract niektóre kodu do sub-funkcji. Np:

    case 'foo' : 
        myVar = 'blah'; 
        break; 
    case 'bar' : 
        myVar = secondLevelFunction(); 
        break; 
    

    Tutaj secondLevelFunction() zawiera dodatkowe switch() oświadczenie gdzie każdy case zwraca wartość myVar.

  2. Użyj mapowania tablicowego.Np:

    var mapper = {'foo':'blah', 'bar':'bibble', etc}; 
    
    //now, instead of a big switch(input) { .... } block that sets myVar 
    //for each option, you can just set it directly in a single line, like so: 
    var myVar = mapper[input]; 
    

Ponadto, jeśli szukasz konkretnych miar jakości kodu, należy dowiedzieć się o Cyclomatic Complexity. Jest to miara złożoności funkcji. Pomiar jest dokonywany poprzez sprawdzenie, ile "punktów decyzyjnych" posiada funkcja. Każda pętla case, if jest "punktem decyzyjnym". Im więcej masz, tym bardziej złożona jest twoja funkcja.

Złożoność cykliczna jest silnie związana z jakością kodu i dobrymi praktykami kodowania, więc jeśli twoja funkcja ma wysoki wynik CC (co prawdopodobnie zrobi, jeśli ma wiele zagnieżdżonych bloków switch), jest to oznaka słabej jakości kodu . Oba rozwiązania alternatywne opisane powyżej mogą pomóc w tym. Zostawię to dla ciebie, aby przeczytać więcej na temat CC.

Oczywiście alternatywne rozwiązania musiałyby być dostosowane do twoich potrzeb, ale mam nadzieję, że dadzą ci kilka pomysłów.