2015-07-11 13 views
9

Ich schaue mir die PSR-7 Schnittstellen an und denke über einen Weg nach, wie man sie implementiert.Psr7 Http Message, warum unveränderlich?

Ich habe auch gelesen this blog post. Offensichtlich müssen die Objekte, die die Schnittstellen PSR-7 implementieren, unveränderbar sein.

Also, wenn ich die withProtocolVersion Methode von MessageInterface implementieren, dann wäre es in etwa so aussehen:

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

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

Meine Frage ist wirklich, warum unveränderlich? Warum nicht einfach eine return $this;?

Es ist nicht so, dass ich über die Menge an Speicher besorgt bin, die es zuweist, ich sehe wirklich keinen Vorteil darin, es unveränderlich zu halten.

Wie die Blog-Posts sagen, wenn Sie dies tun:

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

Dann vier Kopien erstellt werden, aber das Ergebnis Ende in $request ist das gleiche wie wenn ich einfach return $this verwenden würde, nicht wahr?

Warum ist die Entscheidung getroffen, es unveränderlich zu halten. Also, warum muss ich eine clone $this machen? Was bringt das?

Ich bin nicht wirklich auf die Idee, es zu starten.

+3

Der letzte Abschnitt dieses Abschnitts des Blogposts sagt: _Diese Entscheidung wurde aus Gründen der Robustheit getroffen. Das würde "eine ganze Klasse von Fehlern entfernen". – Barmar

+1

@Barmar Ich verstehe nicht wirklich, was er damit meint.Ich sehe nicht wirklich, wie es * eine ganze Klasse von Bug * entfernen würde. Also, wie * würde * das eine Klasse von Fehlern entfernen? Sie können alle Eigenschaften noch "festlegen" *. Es wird nur eine neue Kopie des Objekts anstelle des Objekts selbst zurückgegeben. – Vivendi

Antwort

6

Ich empfehle Ihnen zu lesen this document, wo alle Design-Optionen im Detail erklärt werden.

Insbesondere sollten Sie die Why value objects? und die New instances vs returning $this Abschnitte lesen.

Die wichtigsten Punkte sind:

Im Wesentlichen Modellierung von HTTP-Nachrichten als Wertobjekte gewährleistet die Integrität des Nachrichtenstatus, und verhindert, dass die Notwendigkeit für eine bidirektionale Abhängigkeiten, die oft gehen out- of-sync oder führen zu Debugging- oder Leistungsproblemen.

und

Diese Operationen können auch mit Wertobjekten durchgeführt werden, mit einer Reihe von Vorteilen:

  • Der ursprüngliche Anfrage Zustand kann von jedem Verbraucher zum Abruf gespeichert werden.
  • Ein Standardantwortstatus kann mit Standardheadern und/oder Nachrichtentext erstellt werden.

Wenn Sie tiefer graben wollen, würde ich empfehlen, in der Geschichte der Abb Mailing-Liste zu suchen (Sie können es here finden), wo es viele Diskussionen über die Unveränderlichkeit der Objekte war

+0

Danke, gerade arbeite ich mich durch die Mailingliste. Aber das hat mich bereits dazu gebracht, die Ideen hinter unveränderlichen Anfrageobjekten zu verstehen. – Vivendi

+0

Ich sehe keine Gründe in den Links zur Verfügung gestellt. die Tatsache, dass diese direkte Frage nicht direkt beantwortet wird, sondern mit einigen Links und den gleichen vagen Meinungen. Meinungen über mögliche Missverständnisse anderer Entwickler. Dies beweist mir, dass diese seriöse Designentscheidung nicht fundiert ist und wahrscheinlich nur darauf basiert, wie PHP aktuell und in der Vergangenheit verwendet wird. –