nicht angemeldet
Hallo,
Aber das Problem ist, du kannst mit JS nicht wirklich OO programmieren.
Naja, ob Soshnikov das auch so sieht. Was soll denn "wirklich OO" sein. Javascript is about Objects. Functions are first class Objects. Das ist dann sprachlich schon verwirrend, wenn ich hier nicht von Objektorientiert sprechen möchte. Objektorientiert heißt meines Verständnisses auch, Objekte abzubilden, also Sinnzusammenhänge zu kapseln. Es heißt auch, dass vererbt werden kann. Ob ich nun "extend" schreibe oder "prototyp" ist doch egal.
Objekte ist im Prinzip erstmal nichts weiter, als eine Struktur. Das gibt es auch in C. Nur das vorhanden sein eines Objektes macht noch keine OO Sprache. Aber du hast insoweit recht, dass JS einige rudimentäre Mechanismen der OOP mitbringt. Aber sonst nchts.
Naja, würdest Du wenigstens zustimmen, dass Soshnikov das in diesem Kapitel anders sieht? ("ECMAScript is the object-oriented programming language with the prototype based implementation."). Und im folgenden redet er ja von der OOP-Implementation von ECMA-Script. Da ist von rudimentär nicht die Rede,
Aber es fehlen die grundlegendsten Dinge, echte private Member,
Äh, die sind doch im Funktionsscope geclosed und für innere Funktionen aber weiter verfügbar. Was anderes als das ist das Prinzip von "private"?
Ein private Member ist Klassenweit sichtbar, nicht nur im Konstruktor, dass ist genau das, was Florian mit seinem Code erreichen will.
Naja, vielleicht willst du die Variable ja aber auch nur innerhalb einer Funktion sehen und auf den Konstruktor ganz verzichten. So verstehe ich auch peterS.: "mit dem konsequenten verzicht auf konstruktoren fuer eigene objekttypen entfiele in JavaScript auch der irrglaube ueber >>obj.prototype.constructor<< etwas ueber die natur von >>obj<< zu erfahren<<. sobald mehrfachvererbung ins spiel kommt, hilft auch >>obj instanceof MyConstructor<< nicht weiter." https://forum.selfhtml.org/?t=203423&m=1376347. Und wenn du deinen ganzen Code in einer selbsausführende Funktion packst, bleibt Dein ganzer Klumpatsch doch sowieso nach außen hin komplett privat. Und mir dünkt ja eher, dass man mit Javascript eigentlich viel privater ist als mit "private".
myObj = {
method1 : function () {
var myPrivate = "privat1";
return myPrivate;
}
}
myFunction = function (callback) {
alert(callback());
}
myFunction(myObj.method1);
Ich dachte jetzt, Privatheit entsteht, in dem Du Funktionen als Objekte erster Klasse behandelst, was bedeutet, dass Du Privatheit durch callback-Funktionen erzeugst. Die callback-Funktion entscheidet, was passiert. Alles darin ist privat. Die aufrufende Funktion "weiß" nichts über das, was im callback passiert. Wieviel privater solls denn noch sein?
protected geht gar nicht mehr.
Hm, kommt das nicht wirklich darauf an, wo man die Variablen definiert?
myObj = {
method1 : function () {
var myPrivate = "privat1";
return myPrivate;
}
}
myFunction = function (callback) {
alert(callback());
}
myFunction(myObj.method1);
function object(o) {
function F() {}
F.prototype = o;
return new F();
}
var myExtendedObj = object(myObj);
myFunction(myExtendedObj.method1);
... stattdessen aber protected. Ich kann keine privaten Variablen in Unterfunktionen nutzen so dass sie dann auch vererbbar sind? Das was Crockford priveligierte Funktionen nennt?
Nein. privilegierte Funktionen dürfen auf private Member zugreifen. Normalerweise heißt aber privilegiert, dass du einer anderen Klasse erlaubst auf die privaten member zu zugreifen.
Und dafür kann ich keine Funktion bauen? U.u. auch eine verschachtelte?
protected heißt dass du private Elemente vererben kannst. Das geht mit JS Bordmitteln gar nicht.
Vielleicht macht es ja auch sinn mal nicht ganz allgemein über Vererbung zu reden sondern ganz konkret. Wieviel Vererbungen machen denn Sinn, und in welchen zusammenhängen?
Letztlich bleibt der einzige sinnvolle Weg, so wie es Mathias auch auf seinem Blog beschrieben hat. Private Eigenschaften kennzeichnen, dass sie privat sein sollen und eine einfache Vererbung über die prototype Eigenschaft und den Aufruf der superfunktione über call bzw. apply delegieren.
Naja, das ist ein Weg, um beim programmieren nicht selber durcheinander zu kommen, macht man in Linux ja auch, indem man ein "." voranstellt. "Vorsicht, nicht anpacken". Aber nach außen hin gibt es die Privatheit ja doch, würde ich nach wie vor meinen. Ich sehe diese Konvention mit dem "_" bei YUI aber auch.
Eben weil es eben in JS nicht anders geht. Es ist aber nur eine Krücke und letztlich, wie gesagt, die einzige sinnvolle. In Sprachen die OO Regeln umsetzen, brauchst du diese nicht.
Die Frage ist doch eher, wozu dieser Schutz sinnvoll ist. Wenn zB. eh alles in einem Closure gekapselt ist?
Gruß
jobo
Struppi
JürgenB