JS OOP - Private Eigenschaft

[ebody]

Hallo,

in diesem Beispiel verwende ich eine private Eigenschaft. Im Script selbst kann man nicht von außen (über die Instanz) drauf zugreifen. Gibt man aber in der Chrome WebDev Konsole circle.#_color ein, erhält man den Wert.

Das ist schlecht oder? Oder wie ist das zu bewerten? Nehmen wir an, du als Senior Programmierer stellst eine solche Probeaufgabe und man soll eine Klasse mit einer privaten Eigenschaft erstellen und es würde so umgesetzt.

Wie würdest du das bewerten? Ist es

1. komplett falsch?
2. Unverantwortlich?
3. Ok, gibt aber bessere Möglichkeiten wie WeakMap().
4. Ist richtig so.

class Circle {
	#_color;
	constructor(radius) {
		this.radius = radius;
		this.#_color = 'red';
	}
}

const circle = new Circle(6);
console.log(circle.radius); // 6
console.log(circle.#_color); // Uncaught SyntaxError: Private field '#_color' must be declared in an enclosing class 

Gruß ebody

[Raketenwilli]

Das ist schlecht oder?

„Oder“, denn ein DEBUGGER (der ist Teil der Konsole) muss alle Daten, also auch „private“ zeigen können.

Es ist also unmöglich(¹) Daten vor einem Benutzer zu verbergen, die in einer Software und auf einem OS unter Kontrolle des Benutzers verarbeitet werden.

Die Privatheit der Daten bezieht sich nur auf andere Objekte, Funktionen oder Subroutinen. Mit einem Verbergen vor dem Benutzer hat der Begriff nichts zu tun.

---

¹) Freilich gibt es Benutzer, die Mangels Wissens (oder Interesses und sodann Aktivität) nicht rankommen.

[Rolf B]

Hallo ebody,

die Entwicklerwerkzeuge sind genau das: Entwicklerwerkzeuge. Deshalb lassen sie Dich auf private Elemente zugreifen.

Wenn die Aufgabe lautet, eine Klasse mit einem privaten Datenelement zu erzeugen, dann würde man das genau so, mit einem # Property, tun. Das _ im Namen ist nicht nötig.

Rolf

[Felix Riesterer]

Lieber ebody,

wenn Du private Eigenschaften vor Entwicklerwerkzeugen verbergen willst, dann benötigst Du Closures, damit lokale Variablem im Code Deiner Klasse die Funktionalität von privaten Eigenschaften übernehmen.

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

ich war auch schon drauf und dran, eine Erklärung zu diesem Konzept zu schreiben. Aber es genügt wohl auch ein Link auf das Revealing Module Pattern.

Letztlich ist es aber nur eine Hürde, kein wirklicher Schutz.

Wenn man die Codestelle kennt, die auf die Variablen in der Closure zugreift, dann setzt man dort einen Breakpoint, wartet, bis der Code ausgeführt wird und kann die Closure inspizieren. Oder, wenn ich nur einen Aufruf in die Kapsel kenne, setze ich den Breakpoint auf den Aufruf, steppe hinein und habe Zugriff.

Der einzige Ort, wo Daten vor neugierigen Usern sicher sind, ist der Server.

(Nachtrag: Für einen gewissen Wert von „sicher“ - wenn der Server ein Securityloch hat, ist's mit der Sicherheit vorbei)

Rolf

[Hörnchen]

Eine weitere effektive Methode ist IIFE. Damit lassen sich globale Scopes ausschließen. IIFE ist eine sehr effektive Methode um Namenskonflikte für Variablenbezeichner auszuschließen. Diese wird sehr häufig von komplexen Bibliotheken und Frameworks genutzt die auschließen wollen das es zu Namenkonflikten kommt.

[Rolf B]

Hallo Hörnchen,

das Revealing Module Pattern basiert auf einer IIFE.

ES6-Module und private Eigenschaften von Klassen sind angetreten, um diese und ähnliche Techniken aus der Prä-Harmony-Zeit vor 2015 abzulösen.

Rolf

[Matthias Scharwies]

Servus!

das Revealing Module Pattern basiert auf einer IIFE.

ES6-Module und private Eigenschaften von Klassen sind angetreten, um diese und ähnliche Techniken aus der Prä-Harmony-Zeit vor 2015 abzulösen.

Danke für die Ergänzungen zur Geschichte von JavaScript:

JavaScript/Tutorials/DOM#ES6

1. Sollten wir diese ganzen Listenpunkte mit den Tutorials verlinken?
   • Ich glaube schon. Es ist eine gute Übersicht und passt dort rein. Ich hatte den Einzelartikel "Geschichte und Entstehung" dort hinkopiert, weil er sonst gar nicht verlinkt war.
2. Sollten wir den bereits vorhandenen ES6-Überblick einstampfen und dort integrieren?
   • Es ist ja genau genommen nur eine Linkliste, der nur oben einige kurze Code-Beispiele hat.
   • Meist haben wir zu allen Listenpunkten wenigstens irgendetwas. Jetzt merke ich, warum du inhaltlich immer so gesprungen bist in deiner Wikiarbeit. Von Destrukturierung über die Operatoren **und ... zu BigInt und …
   • Im Idealfall sollten diese Features ja schon in unseren Tutorials enthalten sein.

Herzliche Grüße

Matthias Scharwies

BTW: Bei ul ulist mir des Öfteren aufgefallen, dass der margin-top eher komisch aussieht. Das sollten wir mal irgendwo sammeln. Auf github?

.cf-posting-content ul, .cf-cite .cf-cite-content ul, .cf-event .event-content ul, .cf-mail-content ul, .cf-posting-content-diff ul, .cf-posting-content ol, .cf-cite .cf-cite-content ol, .cf-event .event-content ol, .cf-mail-content ol, .cf-posting-content-diff ol {
  margin-top: 1em;
  padding-left: 2em;
}

[Rolf B]

Hallo Matthias Scharwies,

Sollten wir diese ganzen Listenpunkte mit den Tutorials verlinken? Ich glaube schon.

Ich glaube nicht. Noch nicht. Ich war nämlich fertig, als ich den Link zum Hauptartikel sah. Mann Mann Mann... Die Historie von JavaScript passt eigentlich auch gar nicht auf die Einstiegsseite zum DOM Kurs. Find ich.

Ich werde

• den Abschnitt JavaScript aus Tutorials/DOM entfernen und nur einen Link setzen auf:
• Tutorials/ES6 - und dort den historischen Überblick integrieren
• dort kann man dann Links einbauen. Und den Artikel umbenennen in „Historie“ oder „Entstehung“ oder so. ES6 muss als WL natürlich bleiben.

Das Wiki muss ich dann noch nach Links auf tutorials/dom#was ist javascript durchforsten .

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias Scharwies,

Sollten wir diese ganzen Listenpunkte mit den Tutorials verlinken? Ich glaube schon.

Ich glaube nicht. Noch nicht. Ich war nämlich fertig, als ich den Link zum Hauptartikel sah. Mann Mann Mann... Die Historie von JavaScript passt eigentlich auch gar nicht auf die Einstiegsseite zum DOM Kurs. Find ich.

Ja, aber als eigener Artikel (hier die eingestampfte 2022er Version) hat es eben auch keinen Wert. Das hatten wir aus der Doku übernommen; molily hat bei den Webkrauts 2015 einen Artikel über die Geschichte von JS geschrieben - damals war ES6 - ECMAScript 2015 grade aktuell neu - heute ist es ja selbstverständlich.

Die Frage "Was ist JavaScript?" finde ich da gut platziert.

Die Browserkriege würde ich noch mehr kürzen.

Würde ein eigener Artikel zu ES6 denn aufgerufen/gefunden werden? Wo sollte er verlinkt werden?

Ich werde

• den Abschnitt JavaScript aus Tutorials/DOM entfernen und nur einen Link setzen auf:
• Tutorials/ES6 - und dort den historischen Überblick integrieren
• dort kann man dann Links einbauen. Und den Artikel umbenennen in „Historie“ oder „Entstehung“ oder so. ES6 muss als WL natürlich bleiben.

Das Wiki muss ich dann noch nach Links auf tutorials/dom#was ist javascript durchforsten .

Rolf

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias Scharwies,

Würde ein eigener Artikel zu ES6 denn aufgerufen/gefunden werden? Wo sollte er verlinkt werden?

Nein, kein eigener ES6-Artikel. Ein Artikel von ES1 bis ES2022, der die Entwicklung von JavaScript aufdröselt. Welche Highlights gab es in welcher Version. Den kann man ganz vorne bei den Einsteigerartikeln aufführen und gerne auch auf der DOM Seite verlinken.

Der Artikel muss nicht sehr umfangreich sein, in etwa sollte das drinstehen, was ich im Moment auf der DOM Seite stehen habe.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias Scharwies,

Würde ein eigener Artikel zu ES6 denn aufgerufen/gefunden werden? Wo sollte er verlinkt werden?

Nein, kein eigener ES6-Artikel. Ein Artikel von ES1 bis ES2022, der die Entwicklung von JavaScript aufdröselt. ...

Ja, lass uns am Mittwoch drüber reden!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias Scharwies,

nee, da pack ich die Koffer. Do morgen geht's nach Wien.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias Scharwies,

nee, da pack ich die Koffer. Do morgen geht's nach Wien.

Du glücklicher!

Herzliche Grüße und nen schönen Urlaub!

Matthias Scharwies

[Der Martin]

Hallo,

Ja, lass uns am Mittwoch drüber reden!

diesen Mittwoch bin ich auch verhindert - ein soziales Event in der Firma.

Einen schönen Tag noch
 Martin

[Matthias Scharwies]

Servus!

Hallo Matthias Scharwies,

Würde ein eigener Artikel zu ES6 denn aufgerufen/gefunden werden? Wo sollte er verlinkt werden?

Nein, kein eigener ES6-Artikel. Ein Artikel von ES1 bis ES2022, der die Entwicklung von JavaScript aufdröselt. Welche Highlights gab es in welcher Version. Den kann man ganz vorne bei den Einsteigerartikeln aufführen und gerne auch auf der DOM Seite verlinken.

Der Artikel muss nicht sehr umfangreich sein, in etwa sollte das drinstehen, was ich im Moment auf der DOM Seite stehen habe.

Das finde ich auch!

Ich finde, dass wir genügend Baustellen und Löcher bei aktuellen Sachen haben.

Den Absatz "Was ist JavaScript?" finde ich zu Beginn eines Tutorials (also entweder hier oder im eigentlichen Einstieg) sehr wohl nötig.

Ja, aber als eigener Artikel (hier die eingestampfte 2022er Version) hat es eben auch keinen Wert. Das hatten wir aus der Doku übernommen; molily hat bei den Webkrauts 2015 einen Artikel über die Geschichte von JS geschrieben - damals war ES6 - ECMAScript 2015 grade aktuell neu - heute ist es ja selbstverständlich.

Ob man den Abschnitt Geschichte und Entstehung weiter kürzen sollte, könnte man sich fragen, JScript hatte ja auch in der alten Doku nur eine kleine Rolle gespielt.

[EDIT] Habe ich jetzt mal gemacht! [/EDIT]

Bis jetzt war der Entstehungsartikel ganz weit unten verlinkt:

• JavaScript#weiterführende_Informationen Dort befindet sich die Resterampe der nicht einzusortierenden Seiten.

Evtentuell könnte man, wenn man die JS-Portalseite übersichtlicher präsentiert, diesen Abschnitt ans Ende packen.

Ich glaube nicht, dass die zwei Artikel in deinem Benutzernamensraum die Arbeit im Vergleich zum Nutzen rechtfertigen.

Herzliche Grüße

Matthias Scharwies