public protected and private in javascript

[molily]

Nun ja, gerade in größeren Projekten lässt sich javascript nicht so gut strukturieren. Es ist nur schwerlich umzusetzen welche Klasse jetzt was vom wem benutzen soll und darf und welche nicht.

Es ist doch recht überschaubar, denn soviele Möglichkeiten hat JS da nicht. Entweder man setzt Kapselung effektiv über Closures um, dann ist eine Methode immer »private«. Oder man macht sie effektiv »public«, also sie ist ein ganz normaler Member, versieht sie aber mit einem »_«-Präfix oder ähnlich. Dann kann man prinzipiell auf sie zugreifen, aber es ist offensichtlich, dass man es nicht soll.

Klar, mit Gettern und Settern sowie ES5 habe ich jetzt noch mehr Möglichkeiten, den Zugriff effektiv einzuschränken, ohne Closures zu verwenden. Dein Delegator ähnelt wohl am ehesten Proxies in ECMAScript Harmony.

Und scopes sind da schon eine bereicherung auf die ich nur ungerne verzichten möchte.

Ich habe sie in JavaScript noch nie vermisst. Und ich programmiere auch viel mit klassenbasierten Sprachen, in denen Klassen deklariert werden und Kapselung existiert.

Zudem wollte ich eine möglichst kompate und verständiche lösung haben, wie Klassen definiert werden und mich dabei an anderen statischen OO Programmiersprachen orientieren.

Kompakt und verständlich sind m.M.n. auch bestehende Umsetzungen. Nach außen hin unterscheidet sich der Ansatz ja nicht groß von bestehenden Lösungen, die keine Kapselung umsetzen. Nur dass alle Member bei dir über public/private/protected gesetzt werden. PrototypeJS kommt im Grunde mit 30 Zeilen für die Schreibweise Class.create({ init: function () {}, member: ... }); aus plus Methoden-Wrapping für Super-Calls. Das ist natürlich übersichtlicher als folgende Low-Level-Lösung:

function K1 () {  
   var _privateVar = 'K1';  
   this.method1 = function () { alert(_privateVar); };  
}  
K1.prototype.method2 = function () { alert('method2'); };  
  
function K2 () {  
   K1.call(this);  
   var _privateVar = 'K2';  
   this.method3 = function () { alert(_privateVar); };  
}  
K2.prototype.method4 = function () { alert('method4'); };  
[link:http://molily.de/weblog/javascript-pseudoklassen@title=inheritPseudoClass](K1, K2);

Allerdings weiß man hier genau, was getan wird. Es gibt eine Kapselung mit Bordmitteln (Closures) und ansonsten simple prototypische Vererbung. Das mag Programmierer klassenbasierter Sprachen abschrecken, aber im Grunde sind das die Möglichkeiten, die JS bietet. Die kann ich höchstens mit viel Metaprogramming verstecken und in eine »schönere« Form bringen. Dabei gehen sie oft schlicht verloren, sodass man sie durch noch mehr Metaprogramming wieder nachbauen muss.

Ich Arbeite im Rahemn eines größeren Universitären Bachelor und Master Projektes an einem Objekt Persistenz Layer und möchhte in dessen Rahmen auch eine Möglichkeit schaffen Objekte aus Javascript in eine Datenbank zu speichern. Heirfür benötigt man jedoch einige statische Strukturen in JS auf die ich aufbauen möchte.

Ich wüsste nicht, was Serialisierung direkt mit Sichtbarkeiten zu tun hat. In einer größeren Anwendung in einer klassenbasierten Sprache konnten wir die Sichtbarkeiten dazu nicht wiederverwenden. Stattdessen haben wir es so umgesetzt, wie ich es auch in JS umgesetzt hätte: Es gibt deklarativ Metainformationen für den Serializer. In einem public static Hash steht drin, welche Eigenschaften einer Klasse serialisiert werden sollen und ggf. welche Serialisierungsfunktion (ebenfalls public static) verwendet werden soll.

Mathias