Sposoby wyeliminowania przełącznika w kodzie [zamknięty]

Zobacz Switch Statements :

Zazwyczaj podobne polecenia switch są rozrzucane po całym programie. Jeśli dodasz lub usuniesz klauzulę w jednym przełączniku, często musisz znaleźć i naprawić Pozostałe.

Zarówno Refaktoryzacja jak i Refaktoryzacja do wzorców mają podejście do rozwiązania tego problemu.

Jeśli twój (pseudo) kod wygląda następująco:

class RequestHandler {

    public void handleRequest(int action) {
        switch(action) {
            case LOGIN:
                doLogin();
                break;
            case LOGOUT:
                doLogout();
                break;
            case QUERY:
               doQuery();
               break;
        }
    }
}

Ten kod narusza zasadę otwartą zamkniętą i jest kruchy dla każdego nowy rodzaj kodu działania, który pojawia się. Aby temu zaradzić, możesz wprowadzić obiekt 'Command':

interface Command {
    public void execute();
}

class LoginCommand implements Command {
    public void execute() {
        // do what doLogin() used to do
    }
}

class RequestHandler {
    private Map<Integer, Command> commandMap; // injected in, or obtained from a factory
    public void handleRequest(int action) {
        Command command = commandMap.get(action);
        command.execute();
    }
}

Jeśli twój (pseudo) kod wygląda następująco:

class House {
    private int state;

    public void enter() {
        switch (state) {
            case INSIDE:
                throw new Exception("Cannot enter. Already inside");
            case OUTSIDE:
                 state = INSIDE;
                 ...
                 break;
         }
    }
    public void exit() {
        switch (state) {
            case INSIDE:
                state = OUTSIDE;
                ...
                break;
            case OUTSIDE:
                throw new Exception("Cannot leave. Already outside");
        }
    }

Wtedy można wprowadzić obiekt 'State'.

// Throw exceptions unless the behavior is overriden by subclasses
abstract class HouseState {
    public HouseState enter() {
        throw new Exception("Cannot enter");
    }
    public HouseState leave() {
        throw new Exception("Cannot leave");
    }
}

class Inside extends HouseState {
    public HouseState leave() {
        return new Outside();
    }
}

class Outside extends HouseState {
    public HouseState enter() {
        return new Inside();
    }
}

class House {
    private HouseState state;
    public void enter() {
        this.state = this.state.enter();
    }
    public void leave() {
        this.state = this.state.leave();
    }
}

Sam Switch nie jest taki zły, ale jeśli masz dużo "switch" lub "if/else" na obiektach w metodach, może to być znak, że twój projekt jest trochę "proceduralny" i że Twoje obiekty są po prostu wiadrami wartości. Przenieś logikę do obiektów, wywołaj metodę na obiektach i pozwól im zdecydować, jak odpowiedzieć.

Switch to wzorzec, zaimplementowany z instrukcją switch, if else chain, lookup table, OOP polimorfizm, pattern matching lub coś innego.

Czy chcesz wyeliminować użycie" switch statement "lub"Switch pattern "? Pierwszy z nich można wyeliminować, drugi, tylko wtedy, gdy można użyć innego wzoru/algorytmu, a w większości przypadków nie jest to możliwe lub nie jest to lepsze podejście do tego.

Jeśli chcesz wyeliminować switch statement z kodu, pierwsze pytanie, które należy zadać, to gdzie sensowne jest wyeliminowanie instrukcji switch i użycie innej techniki. Niestety odpowiedź na to pytanie jest specyficzna dla danej domeny.

I pamiętaj, że Kompilatory mogą wykonywać różne optymalizacje, aby zmienić instrukcje. Na przykład, jeśli chcesz efektywnie przetwarzać wiadomości, polecenie switch jest w zasadzie dobrym rozwiązaniem. Ale z drugiej strony prowadzenie reguł biznesowych opartych na zamianie statement prawdopodobnie nie jest najlepszym sposobem, aby przejść i aplikacja powinna zostać ponownie przearchitektowana.

Oto kilka alternatyw dla instrukcji switch:

• tabela wyszukiwania
• polimorfizm
• W 1998 roku w ramach projektu "budowa domu dla dzieci", w 1999 roku, w 1999 roku, w 1999 roku, w 1999 roku, w 1999 roku, w 1999 roku]}

Myślę, że najlepszym sposobem jest użycie dobrej Mapy. Za pomocą słownika można odwzorować prawie każde wejście na inną wartość / obiekt / funkcję.

Twój kod wyglądałby tak (psuedo):

void InitMap(){
    Map[key1] = Object/Action;
    Map[key2] = Object/Action;
}

Object/Action DoStuff(Object key){
    return Map[key];
}

Wszyscy kochają ogromne if else bloki. Tak łatwe do odczytania! Jestem jednak ciekaw, dlaczego chcesz usunąć instrukcje switch. Jeśli potrzebujesz instrukcji switch, prawdopodobnie potrzebujesz instrukcji switch. Poważnie, powiedziałbym, że to zależy od tego, co robi kod. Jeśli wszystko, co robi przełącznik, to wywołanie funkcji (powiedzmy), możesz przekazać Wskaźniki funkcji. Czy jest to lepsze rozwiązanie jest dyskusyjne.

Język jest ważnym czynnikiem również tutaj, myślę.

Myślę, że to, czego szukasz, to wzór strategii.

Można to zaimplementować na wiele sposobów, o których wspomniano w innych odpowiedziach na to pytanie, takich jak:

• Mapa wartości - > funkcje
• polimorfizm. (Podtyp obiektu decyduje o tym, w jaki sposób obsługuje określony proces).
• Funkcje pierwszej klasy.

If-else

Obalam założenie, że przełącznik jest z natury zły.

switch polecenia byłyby dobre do zastąpienia, jeśli dodasz do nich nowe stany lub nowe zachowanie:

int state;

String getString() {
   switch (state) {
     case 0 : // behaviour for state 0
           return "zero";
     case 1 : // behaviour for state 1
           return "one";
   }
   throw new IllegalStateException();
}

double getDouble() {

   switch (this.state) {
     case 0 : // behaviour for state 0
           return 0d;
     case 1 : // behaviour for state 1
           return 1d;
   }
   throw new IllegalStateException();
}

Dodanie nowego zachowania wymaga skopiowania switch, a dodanie nowych stanów oznacza dodanie kolejnego case do co switch oświadczenie.

W Javie można przełączać tylko bardzo ograniczoną liczbę prymitywnych typów, których wartości znasz w czasie wykonywania. Stanowi to problem sam w sobie: Stany są reprezentowane jako liczby magiczne lub postaci.

Pattern matching i wiele if - else bloków mogą być używane, choć naprawdę mają te same problemy przy dodawaniu nowych zachowań i nowych stanów.

Rozwiązanie, które inni zasugerowali jako "polimorfizm", jest instancją wzorca stanu :

Zastąp każdy ze Stanów własną klasą. Każde zachowanie ma swoją własną metodę na klasie:

IState state;

String getString() {
   return state.getString();
}

double getDouble() {
   return state.getDouble();
}

Za każdym razem, gdy dodajesz nowy stan, musisz dodać nową implementację IState interfejs. W świecie switch dodałbyś case do każdego switch.

Za każdym razem, gdy dodajesz nowe zachowanie, musisz dodać nową metodę do interfejsu IState i każdej z implementacji. Jest to takie samo obciążenie jak wcześniej, chociaż teraz kompilator sprawdzi, czy masz implementacje nowego zachowania na każdym istniejącym stanie.

Inni już powiedzieli, że może to być zbyt ciężkie, więc oczywiście jest punkt, do którego się dociera, gdy się przechodzi z jednego do kolejny. Osobiście drugi raz piszę przełącznik to punkt, w którym refaktoruję.

Cóż, po pierwsze, nie wiedziałem, że użycie przełącznika jest anty wzorcem.

Po drugie, switch można zawsze zastąpić poleceniami if / else if.

Dlaczego chcesz? W rękach dobrego kompilatora Instrukcja switch może być znacznie wydajniejsza niż bloki if / else (a także łatwiejsza do odczytania), a tylko największe przełączniki mogą zostać przyspieszone, jeśli zostaną zastąpione przez jakąkolwiek strukturę danych pośredniego wyszukiwania.

'switch' jest tylko konstrukcją języka i wszystkie konstrukcje językowe mogą być traktowane jako narzędzia do wykonania zadania. Podobnie jak w przypadku prawdziwych narzędzi, niektóre narzędzia są lepiej dostosowane do jednego zadania niż inne (nie użyłbyś młota sankowego, aby umieścić hak do zdjęć). Ważną częścią jest to, jak definiuje się "wykonywanie pracy". Czy musi być utrzymywalny, czy musi być szybki, czy musi być skalowany, czy musi być rozszerzalny i tak dalej.

W każdym punkcie procesu programowania są Zwykle zakres konstrukcji i wzorców, które mogą być używane: przełącznik, Sekwencja if-else-if, funkcje wirtualne, tabele skoków, mapy ze wskaźnikami funkcji i tak dalej. Z doświadczeniem programista instynktownie pozna właściwe narzędzie do zastosowania w danej sytuacji.

Należy założyć, że każdy, kto przechowuje lub przegląda kod, jest co najmniej tak wykwalifikowany, jak autor oryginału, aby można było bezpiecznie używać dowolnej konstrukcji.

Jeśli przełącznik służy do rozróżniania różnych rodzajów obiektów, prawdopodobnie brakuje Ci klas do precyzyjnego opisania tych obiektów lub niektórych metod wirtualnych...

Dla C++

Jeśli odnosisz się do ie AbstractFactory myślę, że registerCreatorFunc(..) metoda zwykle jest lepsza niż Wymaganie dodawania case dla każdego "nowego" polecenia, które jest potrzebne. Następnie pozwolić wszystkim klasom utworzyć i zarejestrować creatorFunction(..) które można łatwo zaimplementować za pomocą makra (jeśli ośmielę się wspomnieć). Uważam, że jest to wspólne podejście wielu ram. Po raz pierwszy zobaczyłem go w ET++ i myślę, że wiele frameworków, które wymagają DECL i używa go impl macro.

W języku proceduralnym, takim jak C, wtedy switch będzie lepszy niż jakakolwiek alternatywa.

W języku obiektowym prawie zawsze są dostępne inne alternatywy, które lepiej wykorzystują strukturę obiektu, w szczególności polimorfizm.

Problem z instrukcjami switch pojawia się, gdy kilka bardzo podobnych bloków switch występuje w wielu miejscach w aplikacji i trzeba dodać obsługę nowej wartości. Dość często zdarza się, że programista zapomina aby dodać obsługę nowej wartości do jednego z bloków przełączników rozrzuconych po aplikacji.

Z polimorfizmem, wtedy nowa klasa zastępuje nową wartość, a nowe zachowanie jest dodawane jako część dodawania nowej klasy. Zachowanie w tych punktach przełączania jest następnie dziedziczone z superklasy, nadpisywane, aby zapewnić nowe zachowanie, lub zaimplementowane, aby uniknąć błędu kompilatora, gdy super metoda jest abstrakcyjna.

Tam, gdzie nie ma oczywistego polimorfizmu, może być dobrze warto wdrożyć wzór strategii .

Ale jeśli Twoja alternatywa to duże "jeśli"... Więc ... Albo Zablokuj, to zapomnij.

Użyj języka, który nie ma wbudowanej instrukcji switch. Przychodzi mi na myśl Perl 5.

Poważnie, dlaczego chcesz tego uniknąć? A jeśli masz dobry powód, aby tego uniknąć, dlaczego po prostu nie unikniesz tego wtedy?

Wskaźniki funkcji są jednym ze sposobów na zastąpienie ogromnej instrukcji przełącznika, są one szczególnie dobre w językach, w których można przechwytywać funkcje po ich nazwach i tworzyć z nich rzeczy.

Oczywiście, nie powinieneś wymusić instrukcji switch ze swojego kodu i zawsze jest szansa, że robisz to źle, co skutkuje głupimi zbędnymi fragmentami kodu. (Czasami jest to nieuniknione, ale dobry język powinien pozwolić Ci usunąć redundancję podczas pobytu czysto.)

To jest świetny przykład divide&conquer:

switch(*IP) {
    case OPCODE_ADD:
        ...
        break;
    case OPCODE_NOT_ZERO:
        ...
        break;
    case OPCODE_JUMP:
        ...
        break;
    default:
        fixme(*IP);
}

Zamiast tego możesz użyć tego:

opcode_table[*IP](*IP, vm);

... // in somewhere else:
void opcode_add(byte_opcode op, Vm* vm) { ... };
void opcode_not_zero(byte_opcode op, Vm* vm) { ... };
void opcode_jump(byte_opcode op, Vm* vm) { ... };
void opcode_default(byte_opcode op, Vm* vm) { /* fixme */ };

OpcodeFuncPtr opcode_table[256] = {
    ...
    opcode_add,
    opcode_not_zero,
    opcode_jump,
    opcode_default,
    opcode_default,
    ... // etc.
};

Zauważ, że Nie wiem jak usunąć redundancję opcode_table w C. Może powinienem zadać pytanie na ten temat. :)

Switch nie jest dobrym sposobem, aby przejść, ponieważ łamie otwarte zamknięcie głównego. Tak to robię.

public class Animal
{
       public abstract void Speak();
}


public class Dog : Animal
{
   public virtual void Speak()
   {
       Console.WriteLine("Hao Hao");
   }
}

public class Cat : Animal
{
   public virtual void Speak()
   {
       Console.WriteLine("Meauuuu");
   }
}

A oto jak z niego korzystać (biorąc swój kod):

foreach (var animal in zoo) 
{
    echo animal.speak();
}

Zasadniczo to, co robimy, to delegowanie odpowiedzialności na klasę dziecięcą, zamiast zmuszania rodzica do decydowania, co zrobić z dziećmi.

Najbardziej oczywistą, niezależną od języka, odpowiedzią jest użycie szeregu "jeśli".

Jeśli język, którego używasz ma Wskaźniki funkcji (C) lub funkcje, które są wartościami pierwszej klasy (Lua), możesz uzyskać wyniki podobne do "przełącznika" za pomocą tablicy (lub listy) wskaźników do funkcji.

Powinieneś być bardziej dokładny w języku, jeśli chcesz lepszych odpowiedzi.

Polecenia Switch często można zastąpić dobrym projektem OO.

Na przykład masz klasę konta i używasz instrukcji switch do wykonywania różnych obliczeń w zależności od typu konta.

Sugerowałbym, aby to zostało zastąpione przez kilka klas kont, reprezentujących różne typy kont, a wszystkie implementujące interfejs kont.

Przełącznik staje się wtedy niepotrzebny, ponieważ wszystkie typy kont można traktować tak samo i dzięki polimorfizmowi zostaną przeprowadzone odpowiednie obliczenia dla typu konta.

Zależy dlaczego chcesz go wymienić!

Wiele interpreterów używa' computed gotos ' zamiast instrukcji switch do wykonywania kodu opcode.

Brakuje mi w C / C++ switch 'a Pascala' w ' i zakresów. Chciałbym też przełączyć się na struny. Ale te, choć trywialne dla kompilatora do jedzenia, są ciężką pracą przy użyciu struktur, iteratorów i innych rzeczy. Wręcz przeciwnie, jest wiele rzeczy, które chciałbym wymienić na przełącznik, gdyby tylko przełącznik C () był bardziej elastyczny!

W JavaScript za pomocą tablicy asocjacyjnej:
to:

function getItemPricing(customer, item) {
    switch (customer.type) {
        // VIPs are awesome. Give them 50% off.
        case 'VIP':
            return item.price * item.quantity * 0.50;

            // Preferred customers are no VIPs, but they still get 25% off.
        case 'Preferred':
            return item.price * item.quantity * 0.75;

            // No discount for other customers.
        case 'Regular':
        case
        default:
            return item.price * item.quantity;
    }
}

Staje się to:

function getItemPricing(customer, item) {
var pricing = {
    'VIP': function(item) {
        return item.price * item.quantity * 0.50;
    },
    'Preferred': function(item) {
        if (item.price <= 100.0)
            return item.price * item.quantity * 0.75;

        // Else
        return item.price * item.quantity;
    },
    'Regular': function(item) {
        return item.price * item.quantity;
    }
};

    if (pricing[customer.type])
        return pricing[customer.type](item);
    else
        return pricing.Regular(item);
}

Uprzejmość

Kolejny głos na if / else. Nie jestem wielkim fanem case lub switch statements, ponieważ są ludzie, którzy ich nie używają. Kod jest mniej czytelny, jeśli używasz case lub switch. Może nie mniej czytelne dla ciebie, ale dla tych, którzy nigdy nie musieli używać polecenia.

If/else bloki są prostą konstrukcją, którą każdy otrzymuje. Jest kilka rzeczy, które możesz zrobić, aby upewnić się, że nie powodują problemów.

Po pierwsze - nie próbuj i wcięcia if wypowiedzi więcej niż kilka razy. Jeśli znajdujesz się wcięty, to robisz to źle.

 if a = 1 then 
     do something else 
     if a = 2 then 
         do something else
     else 
         if a = 3 then 
             do the last thing
         endif
     endif 
  endif

Jest naprawdę źle-zrób to zamiast tego.

if a = 1 then 
   do something
endif 
if a = 2 then 
   do something else
endif 
if a = 3 then 
   do something more
endif 

Po drugie, nie jestem przeciwny wyłamywaniu się z bloku If tak długo, jak jest wystarczająco dużo instrukcji breaks rozrzuconych po danym bloku kodu, aby było to oczywiste

procedure processA(a:int)
    if a = 1 then 
       do something
       procedure_return
    endif 
    if a = 2 then 
       do something else
       procedure_return
    endif 
    if a = 3 then 
       do something more
       procedure_return
    endif 
end_procedure

EDIT : Na Switch i dlaczego wg mnie ciezko grac:

Oto przykład instrukcji switch...

private void doLog(LogLevel logLevel, String msg) {
   String prefix;
   switch (logLevel) {
     case INFO:
       prefix = "INFO";
       break;
     case WARN:
       prefix = "WARN";
       break;
     case ERROR:
       prefix = "ERROR";
       break;
     default:
       throw new RuntimeException("Oops, forgot to add stuff on new enum constant");
   }
   System.out.println(String.format("%s: %s", prefix, msg));
 }

Dla mnie problem polega na tym, że normalne struktury kontrolne, które mają zastosowanie w językach podobnych do C, zostały całkowicie złamane. Istnieje ogólna zasada, że jeśli chcesz umieścić więcej niż jeden wiersz kodu wewnątrz struktury kontrolnej, używasz szelek lub instrukcji begin/end.

Np.

for i from 1 to 1000 {statement1; statement2}
if something=false then {statement1; statement2}
while isOKtoLoop {statement1; statement2}

Dla mnie (i możesz mnie poprawić, jeśli się mylę), oświadczenie sprawy rzuca to wyklucz przez okno. Warunkowo wykonany blok kodu nie jest umieszczony wewnątrz struktury begin/end. Z tego powodu uważam, że ten przypadek jest na tyle odmienny koncepcyjnie, że nie może być użyty.