Ventajas de múltiples métodos sobre Switch

Un cambio no se considera OOP porque a menudo polimorfismo puede hacer el truco.

En su caso, una implementación de OOP podría ser esta:

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();

para este ejemplo:

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

Está bien, sólo estoy bromeando parcialmente aquí. El argumento a favor / en contra del uso de una instrucción de cambio no se puede hacer con fuerza con un ejemplo tan trivial, porque el lado de la POO depende de la semántica involucrada, no simplemente del mecanismo de envío .

Las declaraciones de cambio suelen ser una indicación de clases o clasificaciones faltantes, pero no necesariamente. A veces, una declaración de cambio es solo una declaración de cambio .

Quizás no sea una respuesta, pero en el caso del código que no es de conmutación, parece que esto sería una mejor coincidencia:

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 gran parte del rompecabezas a evaluar es lo que sucede cuando necesitas crear NewSwitch o NewOop . ¿Sus programadores tienen que saltar a través de aros por un método u otro? ¿Qué sucede cuando cambian las reglas, etc.?

En lugar de simplemente poner su código de ejecución en funciones, implemente un patrón de comando completo y coloque cada uno de ellos en su propia clase que implementa una interfaz común. Este método le permite utilizar IOC / DI para conectar los diferentes "casos" de su clase y le permite agregar y eliminar casos de su código fácilmente a lo largo del tiempo. También le proporciona una buena cantidad de código que no viola los principios de programación SOLID.

Creo que el ejemplo es malo. Si hay una función go () que acepta el argumento $ donde, si es perfectamente válido usar el interruptor en la función. Tener una única función go () facilita la modificación del comportamiento de todos los go_where () scenarious. Además, conservará la interfaz de clase: si utiliza varios métodos, modificará la interfaz de la clase con cada nuevo destino.

En realidad, el interruptor no debe reemplazarse con un conjunto de métodos, sino con un conjunto de clases, esto es polimorfismo. Entonces el destino será manejado por cada subclase, y habrá un solo método go () para todos ellos. Reemplazar condicional con polimorfismo es una de las refactorizaciones básicas, descrita por Martin Fowler. Pero es posible que no necesite polimorfismo, y el cambio es el camino a seguir.