Ha senso interrompere un'interfaccia fluida se viene passato un argomento errato?

Question

Ha senso interrompere un'interfaccia fluida se viene passato un argomento errato?

#1 da (1 voti)

0

Se incateno alcuni setter e uno di loro non restituisce $ this, allora avrò un errore fatale. Ma forse è una buona cosa.

$object = new object();
$object->set('name','foo')->set('number',12)->set('color'=>'brown');

class object {
  protected $name;
  protected $number;
  protected $color;

  protected $allowed_to_set = array('name','color');

  public function set($property,$value) {
    if(!in_array((string)$property,$this->allowed_to_set)) {
      return false;
    } else {
      $this->$property = $value;
      return $this;
    }
  }
}

interfaces php

posta Buttle Butkus 22.02.2014 - 04:08

fonte

1 risposta

Leggi altre domande sui tag interfaces php

Potrebbe essere sufficiente un campione per un allenamento perceptron? Domanda relativa al tempo di esecuzione

score 1 · Answer 1

Consiglio vivamente di non farlo:

I metodi dovrebbero sempre restituire un tipo. I linguaggi tipizzati statici fanno rispettare questo. Restituire diversi tipi comporta ulteriori oneri per il destinatario. Prima di elaborare il risultato si devono fare noiosi controlli di tipo.
Il tuo codice può innescare errori fatali di php: quando set('name','foo') restituisce false, la chiamata successiva sarà false->set('number',12) che attiverà un errore PHP. Ovviamente questo non è ciò che intendevi, giusto:)
Ignorare l'errore è altrettanto brutto. Il chiamante si aspetta che una chiamata abbia un certo effetto. Non ottenere feedback su qualcosa che non va implica che la chiamata sia riuscita.

Secondo me ci sono due approcci possibili qui:

Rimuovi l'interfaccia fluente e restituisci sempre un valore booleano.
Genera un'eccezione se al chiamante non è consentito impostare la proprietà. Per questo è necessario fornire un modo per verificare se al chiamante è consentito impostare la proprietà in precedenza. Considererei una cattiva pratica provare & errore se posso fare qualcosa.

Quale sceglierai dipende da te e dal tuo caso d'uso. Il primo indica che le proprietà non valide sono un caso d'uso valido in cui si rifiuta semplicemente di impostare la proprietà. Il secondo indica un caso d'uso non valido.

Ultimo: non lasciare che il tuo design & l'architettura è guidata da interfacce fluenti. Sono utili per l'usabilità della tua API e in realtà sono solo una scorciatoia che ti piace usare.