Was ist der Vorteil von Object.freeze () nicht einzufrieren Objekte innerhalb des übergebenen Objekts?

8

Ich habe mehr über die Methoden von% s Object -Konstruktor von JavaScript in MDN gelernt, und mir ist aufgefallen, dass der letzte Satz von Object.freeze's Beschreibung lautet:

  

Beachten Sie, dass Werte, die Objekte sind, immer noch geändert werden können, sofern sie nicht ebenfalls eingefroren sind.

Ein solches Verhalten scheint so zu sein, als sollte es sich anmelden. Was genau ist der Vorteil, die Objekte eines eingefrorenen Objekts rekursiv manuell einzufrieren?

Wenn ich ein Objekt einfriere, warum sollte ich wollen, dass die darin enthaltenen Objekte noch veränderbar sind?

    
aleclarson 18.02.2014, 06:36
quelle

4 Antworten

4

Die Antwort liegt im Punkt selbst

%Vor%

Aktualisierung:

  

Es gibt keine offiziellen Informationen bezüglich der Design-Entscheidung der freeze () -Methode

Ich denke, im Grunde aus Leistungsgründen haben sie diese Entscheidung getroffen. Wenn wir die internen Objekte auch eingefroren haben wollen, müssten wir die Methode rekursiv anwenden . Das ist also ein großer Aufwand, daher wurde die Designentscheidung getroffen, dies zu vermeiden.

  

Wenn es nicht die Leistung wäre, hätte sich die Methode verhalten   anders.

    
Shaik Mahaboob Basha 18.02.2014, 06:46
quelle
11

Ich denke, wenn rekursiv die Standardstrategie ist, könnten sich einige komplexe Objekte nicht wie erwartet verhalten. Denken Sie über folgende Situation nach:

%Vor%

und aus irgendeinem Grund möchte ich die stem einfrieren, also habe ich diesen Code geschrieben:

%Vor%

Wenn es rekursiv einfriert, wäre leaf ebenfalls eingefroren, und es scheint OK: Wenn ich stem einfrieren möchte, möchte ich auch seine Kinder einfrieren.

Aber Achtung, stem hat eine andere Eigenschaft - Es hat auch parentElement . Also was wird passieren? Wenn ich stem einfriere, friere ich auch stem.parentElement und stem.parentElement.parentElement ein ... Das ist nie was ich will.

    
张实唯 27.08.2015 07:47
quelle
1

Wenn Sie darüber nachdenken, wird wahrscheinlich das Einfrieren von referenzierten Objekten verhindert, auf die auch an anderer Stelle verwiesen wird (wodurch ein anderer Codeabschnitt deaktiviert wird, der dasselbe Objekt verwendet). Meine Antwort darauf wäre:

Ich habe nicht vorgeschlagen, dass es so funktioniert. Object.freeze() würde mehr Sinn ergeben, wenn der Zustand des Objekts vollständig erfasst wird. Die Referenzen (auf die Objekte) selbst könnten unveränderlich sein, aber das referenzierte Objekt wäre nicht eingefroren.

Wenn ich das gemacht habe ...

%Vor%

... es würde Sinn machen, dass ich nicht möchte, dass name geändert wird AND Ich möchte nicht, dass das likes des Freundes von doStuff() geändert wird. Aber ich möchte immer likes ändern (so wie ich name ändern könnte), zB von doStuff() 's Objektverweis auf friend auch ändern.

Bearbeiten: Nachdem ich Shaiks Antwort gelesen habe, verstehe ich, warum sie es so machen, wie sie es tun. Um die Funktionalität zu erhalten, die ich in diesem Beispiel benötigen würde, würde ich Folgendes tun:

%Vor%

Gibt es irgendwelche damit verbundenen Probleme?

    
aleclarson 18.02.2014 06:52
quelle
0

Es hängt alles von der Situation ab. Möglicherweise möchten Sie ein Objekt einfrieren, um zu verhindern, dass ein neuer Eigenschaftensatz hinzugefügt oder entfernt wird. Sie können jedoch auch vorhandene Eigenschaften ändern. Wenn nicht, friere sie einfach ein! IIRC, Sie können nur das übergeordnete Objekt einfrieren. Untergeordnete Objekte müssen ebenfalls rekursiv eingefroren werden.

    
Sterling Archer 18.02.2014 06:45
quelle

Tags und Links