Vantaggi di più metodi su Switch

Un interruttore non è considerato 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, scherzando solo parzialmente qui. L'argomento per / contro l'uso di un'istruzione switch non può essere strongmente realizzato con un esempio così banale, perché il lato OOP dipende dalla semantica coinvolta, non solo dal meccanismo di invio .

Le dichiarazioni 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 è ciò che accade quando devi creare NewSwitch o NewOop . I tuoi programmatori devono saltare i cerchi con un metodo o l'altro? Cosa succede quando le tue regole cambiano, ecc.

Invece di mettere semplicemente in esecuzione il proprio codice di esecuzione, implementare un modello di comando completo e posizionare ciascuno di essi nella propria classe che implementa un'interfaccia comune. Questo metodo consente di utilizzare IOC / DI per cablare i diversi "casi" della classe e consente di aggiungere e rimuovere facilmente casi dal codice nel tempo. Fornisce anche un bel po 'di codice che non viola i principi di programmazione SOLID.

Penso che l'esempio sia cattivo. Se esiste una funzione go () che accetta l'argomento $ where, se è perfettamente valido utilizzare switch nella funzione. Avere una singola funzione go () rende più semplice modificare il comportamento di tutti go_where (). Inoltre, manterrai l'interfaccia di classe: se utilizzi vari metodi, modifichi l'interfaccia della classe con ogni nuova destinazione.

In realtà, l'opzione non deve essere sostituita con un insieme di metodi, ma con un insieme di classi: questo è il polimorfismo. Quindi la destinazione sarà gestita da ciascuna sottoclasse e ci sarà un metodo single go () per tutti. Sostituisci con il polimorfismo condizionale è uno dei refactoring di base, descritto da Martin Fowler. Ma potresti non aver bisogno del polimorfismo e cambiare è la strada da percorrere.