Private Klassen-Eigenschaften

[Reinhard]

Hey,

Ich nutze ja das Revealing Module Pattern, aber ich frage mich, inwiefern die besagte reverse Methode sinnvoll ist. Auf der einen Seite gehört sie insofern zur Klasse, als dass sie eine solche Klasse als Parameter (oder this-Kontext) erwartet, auf der anderen Seite ist es eine Helferfunktion und damit nicht als API-Methode gedacht.

Unsichtbare Helferfunktionen sind immer gut, um Code-Duplikation zu vermeiden, und gleichzeitig die öffentliche Schnittstelle schmal zu halten. Sie hat also definitiv ihre Existenzberechtigung. Wie genau die Datenkapselung am besten umzusetzen ist, ist dann von Anwendungsfall zu Anwendungsfall zu entscheiden. Da lässt sich keine Regel an einem abstrakten Beispiel ausmachen.

Das ist schon ziemlich frustrierend, dass es doch so vieles gibt, auf das es keine klare Aussage gibt, wie „Das ist besser, weil ...“. Besonders, wenn man nicht wirklich auf Erfahrung zurückblicken kann.

Symbol() würde, wie @1unitedpower angemerkt hat, die Helferfunktion als pseudo-private Methode in der API verfügbar machen, aber hätte einen engeren Kontext zur Klasse als wenn auf eine private Variable referenziert werden würde.

Die Lösung habe ich vorgeschlagen, weil sie der Datenkapselung aus klassischen Programmiersprachen sehr nahe kommt und ich vermutete, dass du nach solch einem Muster suchst.

Die Lösung mit Symbol geht in die Richtung zu dem, was ich suche: Innerhalb der Methoden kann ich mit this schalten und walten, da die Methode im Prototyp sitzt, und nach außen hin ist sie so gut wie unsichtbar.
Meine beiden Beispiele sind nach außen hin vollkommen unsichtbar, aber ich muss entweder die Klasse als Parameter übergeben, oder die Funktion mit call() im Kontext der Klasse ausführen.
Mit Symbol habe ich nun drei Ansätze. Bestimmt hat jeder sein Für und Wider, aber mangels Erfahrung weiß ich nicht, wie ich mich für einen entscheiden soll.

Nichtsdestotrotz, wenn die Verfügbarkeit von Symbol() nicht sicher ist, wären wir doch wieder bei meinem Ausgangsposting.

Der native Browsersupport für EcmaScritp2015 ist heute schon ganz gut. Chrome 98%, FF 90%, Edge 90%. Bis man sie aber guten Gewissens produktiv einsetzen kann, dauert es noch eine ganze Weile, weil man meistens auch ältere Browserversionen unterstützen möchte. Dafür gibt es heute schon Compiler, die EcmaScript2015 Code lesen und in eine niedrigere Version übersetzen.

Wie werden denn bspw. Symbols nach ES5 kompiliert? Das hört sich ziemlich abenteuerlich an, wenn man folgendes bedenkt: typeof Symbol() === 'symbol' // true

Mit TypeScript kannst du sogar bis herunter zu EcmaScript 3 kompilieren. Es gibt heute aus meiner Sicht keine guten Gründe mehr dafür noch länger zu warten und sich mit dem vergleichsweise schmalen Sprachkern von EcmaScript 5.1 abzumühen.

Ich weiß gar nicht, was es alles in ES3 nicht gibt. Als ich angefangen habe mich mit JS zu beschäftigen, gab es schon eine ganze Weile ES5. Von ES6 wollte ich erst gar nichts wissen, nachdem ich diese Arrow-Funktionen gesehen habe. [1, 2, 3].map(item => item * item) – das sah so schrecklich aus, wer, der davon keine Ahnung hat, sollte daraus schlau werden?
Später habe ich mir aber doch alles durchgelesen, was ES6 zu bieten hat, und es ist gar nicht mal soo schlecht. Ganz vorne dabei sind für mich Default-Parameter, Template-Strings und vielleicht Destructuring. Proxies und Reflection dagegen sind ziemlich ... extrem.
Heute sieht der Einzeiler mit Arrow-Funktion doch irgendwie ganz schick aus.

Reinhard