Vantaggi di più metodi rispetto a Switch

Oggi ho ricevuto una recensione del codice da uno sviluppatore senior che mi chiedeva "A proposito, qual è la tua obiezione alle funzioni di invio tramite un'istruzione switch?" Ho letto in molti posti su come pompare un argomento attraverso il passaggio ai metodi di chiamata è un OOP negativo, non così estensibile, ecc. Tuttavia, non riesco davvero a trovare una risposta definitiva per lui. Vorrei risolverlo una volta per tutte.

Ecco i nostri suggerimenti sul codice concorrenti (php usato come esempio, ma può essere applicato in modo più universale):

class Switch {
   public function go($arg) {
      switch ($arg) {
         case "one":
            echo "one\n";
         break;
         case "two":
            echo "two\n";
         break;
         case "three":
            echo "three\n";
         break;
         default:
            throw new Exception("Unknown call: $arg");
         break;
      }
   }
}

class Oop {
   public function go_one() {
      echo "one\n";
   }
   public function go_two() {
      echo "two\n";
   }
   public function go_three() {
      echo "three\n";
   }
   public function __call($_, $__) {
      throw new Exception("Unknown call $_ with arguments: " . print_r($__, true));
   }
}

Parte del suo argomento era "It (switch method) ha un modo molto più pulito di gestire i casi predefiniti rispetto a quello che hai nel metodo magico __call () generico".

Non sono d'accordo sulla pulizia e in effetti preferisco chiamare, ma mi piacerebbe sentire quello che gli altri hanno da dire.

Argomenti che posso trarre a sostegno dello Oopschema:

• Un po 'più pulito in termini di codice che devi scrivere (meno, più facile da leggere, meno parole chiave da considerare)
• Non tutte le azioni delegate a un singolo metodo. Non c'è molta differenza nell'esecuzione qui, ma almeno il testo è più compartimentato.
• Allo stesso modo, un altro metodo può essere aggiunto in qualsiasi punto della classe anziché in uno spot specifico.
• I metodi sono spaziati, il che è carino.
• Non si applica qui, ma considera un caso in cui Switch::go()operato su un membro piuttosto che su un parametro. Dovresti prima cambiare il membro, quindi chiamare il metodo. Perché Ooppuoi chiamare i metodi in modo indipendente in qualsiasi momento.

Argomenti che posso trarre a sostegno dello Switchschema:

• Per ragioni di argomento, un metodo più pulito per gestire una richiesta predefinita (sconosciuta)
• Sembra meno magico, il che potrebbe far sentire gli sviluppatori sconosciuti a proprio agio

Qualcuno ha qualcosa da aggiungere per entrambe le parti? Mi piacerebbe avere una buona risposta per lui.

Un interruttore è considerato non OOP perché spesso il polimorfismo può fare il trucco.

Nel tuo caso, un'implementazione OOP potrebbe essere questa:

class Oop 
{
  protected $goer;

  public function __construct($goer)
  {
    $this->goer = $goer;
  }

  public function go()
  {
    return $this->goer->go();
  }
}

class Goer
{
  public function go()
  {
    //...
  }
}

class GoerA extends Goer
{
  public function go()
  {
    //...
  }
}

class GoerB extends Goer
{
  public function go()
  {
    //...
  }
}

class GoerC extends Goer
{
  public function go()
  {
    //...
  }
}


$oop = new Oop(new GoerB());
$oop->go();

per questo esempio:

class Switch
{
    public function go($arg)
    {
        echo "$arg\n";
    }
}

OK, sto scherzando solo parzialmente qui. L'argomento a favore / contro l'uso di un'istruzione switch non può essere fortemente espresso con un esempio così banale, poiché il lato OOP dipende dalla semantica coinvolta, non semplicemente dal meccanismo di invio .

Le istruzioni switch sono spesso un'indicazione di classi o classificazioni mancanti, ma non necessariamente. A volte un'istruzione switch è solo un'istruzione switch .

Forse non è una risposta, ma nel caso del codice non-switch, sembra che questa sarebbe una corrispondenza migliore:

class Oop {
  /**
   * User calls $oop->go('one') then this function will determine if the class has a 
   * method 'go_one' and call that. If it doesn't, then you get your error.
   * 
   * Subclasses of Oop can either overwrite the existing methods or add new ones.
   */
  public function go($arg){

    if(is_callable(array($this, 'go_'. $arg))){
      return call_user_func(array($this, 'go_'. $arg));
    }

    throw new Exception("Unknown call: $arg");
  }

  public function go_one() {
    echo "one\n";
  }
  public function go_two() {
    echo "two\n";
  }
  public function go_three() {
    echo "three\n";
  }
}

Una grande parte del puzzle da valutare è cosa succede quando è necessario creare NewSwitcho NewOop. I tuoi programmatori devono saltare attraverso i cerchi con un metodo o l'altro? Cosa succede quando cambiano le tue regole, ecc.

Invece di mettere semplicemente il tuo codice di esecuzione in funzioni, implementa un modello di comando completo e posiziona ognuno nella propria classe che implementa un'interfaccia comune. Questo metodo consente di utilizzare IOC / DI per collegare i diversi "casi" della classe e consente di aggiungere e rimuovere facilmente i casi dal codice nel tempo. Ti dà anche un buon po 'di codice che non viola i principi di programmazione SOLID.

Penso che l'esempio sia negativo. Se esiste una funzione go () che accetta l'argomento $ where, if è perfettamente valido per usare switch nella funzione. La funzione single go () semplifica la modifica del comportamento di tutti gli scenari go_where (). Inoltre, manterrai l'interfaccia della classe: se usi vari metodi, stai modificando l'interfaccia della classe con ogni nuova destinazione.

In realtà il cambio non dovrebbe essere sostituito con un insieme di metodi, ma con un insieme di classi: questo è polimorfismo. Quindi la destinazione verrà gestita da ciascuna sottoclasse e ci sarà un singolo metodo go () per tutti. Sostituire condizionale con polimorfismo è uno dei refactoring di base, descritto da Martin Fowler. Ma potresti non aver bisogno del polimorfismo e cambiare è la strada da percorrere.