nicht angemeldet
Ah, das liegt daran, dass „for in“ nur die öffentlichen Member sieht?
Ist das immer so
Ja. for-in zeigt alle »enumerable« (iterierbaren) Member.
Das sind bei eigenen Objekten alle Objekteigenschaften (nicht enumerable sind nur einige interne Member). Die sogenannten privaten Member sind überhaupt keine Objekteigenschaften, weder iterierbare noch nicht iterierbare, und daher auch nicht für for-in sichtbar.
Hätten die clone-Funktionen Zugriff auf die privaten Member, wenn ich sie dem Objekt anhänge und damit aus dem Kontext des Objekts starte?
Nein, das alleine reicht nicht. Ob sie dem Objekt anhängen oder nicht, ist nicht das entscheidende.
Die ganze Magie von privaten Membern in JS besteht darin, dass man Funktionen im Konstruktor verschachtelt.
function Konstruktor () {
var privateEigenschaft;
this.verschachtelteFunktion = function () { /* Dies ist eine Closure, die privateEigenschaft einschließt */ };
}
Alle Funktionen, die du in der Konstruktorfunktion notierst, schließen dessen lokale Variablen ein. Sie sind somit die einzigen, die nach Ablauf der Konstruktorfunktion noch Zugriff darauf haben.
Für mich ist es kein Unterschied, ob die Felder privat oder öffentlich sind. Ich hab das nur so gemacht, weil in den Tutorien empfohlen wird, interne Objekte privat zu halten und zur Kommunikation nach außen eine öffentliche Schnittstelle anzubieten.
Das ist im Prinzip richtig, aber in JavaScript ist das alles sehr speziell und die OOP-Schulmedizin ist in dem Punkt nicht auf JS anwendbar.
Wenn du das Objekt von außen Klonen willst, dann bau dir eine spezifisch Klonfunktion, die die relevanten Eigenschaften über öffentliche Getter abfragt, eine neue Instanz erstellt und die zuvor ausgelesenen Eigenschaften über die Setter auf die neue Instanz überträgt. Mein Vorschlag wäre, diese gleich als Methode am Objekt anzubieten.
Mit generischen Klonfunktionen kommst du da jedenfalls nicht weiter, wenn nicht alle Eigenschaften öffentlich sind.
Mathias