2015-07-11 19 views
9

Sto osservando le interfacce PSR-7 e sto pensando a come implementarle.Psr7 Http Message, perché immutabile?

Ho letto anche this blog post. Apparentemente gli oggetti che implementano le interfacce PSR-7 devono essere immutabili.

Quindi, se a implementare il metodo withProtocolVersion da MessageInterface allora sarebbe simile a questa:

public function withProtocolVersion($version) 
{ 
    if ($this->protocol === $version) 
    { 
     return $this; 
    } 

    $new = clone $this; 
    $new->protocol = $version; 
    return $new; 
} 

La mia domanda è veramente, perché immutabili? Perché non fare semplicemente un return $this;?

Non è che sono preoccupato per la quantità di memoria allocata, ma non vedo alcun vantaggio nel mantenerlo immutabile.

Come i post del blog dice, quando si esegue questa operazione:

$request = $request 
    ->withMethod('POST') 
    ->withUrl(new Url('http://example.org/') 
    ->withHeader('Content-Type', 'text/plain'); 

Poi vengono creati quattro copie, ma il risultato finale in $request è la stessa di quando vorrei semplicemente utilizzare return $this, giusto?

Perché è stata presa la decisione di mantenerlo immutabile. Quindi, perché devo fare un clone $this? Qual è il vantaggio di questo?

Non ho davvero capito l'idea.

+3

L'ultimo paragrafo di quella sezione del post del blog dice: _ Questa decisione è stata presa per motivi di robustezza. Questo a quanto pare "rimuoverebbe un'intera classe di bug" ._ – Barmar

+1

@Barmar Non capisco davvero cosa intenda.Non vedo davvero come sarebbe * rimuovere un'intera classe di bug *. Quindi, come * dovrebbe * rimuovere una classe di bug? Sei ancora in grado di * "impostare" * tutte le proprietà. L'unica cosa che fa è restituire una nuova copia dell'oggetto invece dell'oggetto stesso. – Vivendi

risposta

6

Ti suggerisco di leggere this document, dove tutte le scelte di progettazione sono spiegate in dettaglio.

In particolare è necessario leggere le sezioni Why value objects? e New instances vs returning $this.

I punti chiave sono i seguenti:

In sostanza, modellando messaggi HTTP come oggetti di valore assicura l'integrità dello stato messaggio, e impedisce la necessità di dipendenze bidirezionali, che spesso può andare out- di sincronizzazione o portare a problemi di debug o prestazioni.

e

Queste operazioni può essere realizzato con gli oggetti di valore e, con una serie di vantaggi:

  • Lo stato richiesta originale può essere conservato per il recupero da qualsiasi consumatore.
  • È possibile creare uno stato di risposta predefinito con intestazioni predefinite e/o corpo del messaggio.

Se si vuole scavare più a fondo, io consiglierei di guardare nella storia del fico mailing list (che si può trovare here), dove c'era un sacco di discussione per quanto riguarda l'immutabilità degli oggetti

+0

Grazie, attualmente sto lavorando sulla mailing list. Ma questo mi ha già fatto capire le idee dietro gli oggetti di richiesta immutabili. – Vivendi

+0

Non vedo i motivi nei collegamenti forniti. il fatto che a questa domanda diretta non si risponda direttamente, ma con alcuni collegamenti e le stesse opinioni vaghe. Opinioni su possibili malintesi di altri sviluppatori. Questo dimostra a me, che questa seria decisione di progettazione non è ben fondata e probabilmente basata solo su come il php è usato e si comporta attualmente/in modo pastoso. –