public protected and private in javascript

[Florian Bücklers]

Hi,

hui ihr habt mir das aber ganz schön kompliziert gemacht hier noch zu kommentieren ;-)

Ich glaube aus genau dem Grund, hat Florian sein FW entwickelt.

Jep, Struppi hat mich verstanden ;-). Ich habe nichts gegen die native
Umsetzung von OOP in JS. Aber (tut mir Leid das ich jetzt auch noch mal auf
deinem Beispiel rumhacke molily) das war einfach mal das Paradebeispiel dafür warum ich die nativen Lösungen alle nicht allzu Prickelnd finde.

Ich habe mir deinen Code angesehen und mich auch zuerst gefragt warum er nicht Funktioniert. Ich muss ehrlicher weise zugeben das ich deinen Artikel noch nicht gelesen habe und somit deine inheritPseudoClass Funktion noch nicht kannte. Erst als ich mir die Implementierung agesehen habe wurde mir klar warum method4 nicht existiert.

Das Hauptproblem was ich bei nativen Umsetzung sehe ist, dass man Funktionen aufrufen muss nachdem man seine eigentliche Klassendefinition geschrieben hat, um die Logik seiner Klasse zu Komplettisieren.

So muss man beispielsweise den prototypen seine Klasse nachträglich setzen, oder sich irgendwo Methoden zwischen merken wenn man sie kurz darauf Überschreiben will, aber diese dennoch aufrufen will (super call).

Hat man eine kleinere Wrapper Funktion die diese grundlogick der Vererbung übernehmen, wie deine inheritPseudoClass kommen genau solche Probleme zum Zug
Wann muss ich welche Funktion rufen und wann wo welche Methode deklarieren.

Prototyping ist genial wenn man Funktionalitäten von Bibliotheken oder bestehenden Klassen erweitern will, aber sein Gundlogik so aufzubauen und zusammen zu halten ist jedoch sehr umständlich mit Prototyping.

Jetzt zu den bestehenden Frameworks. Ja durchaus gibt es ein Reihe von Frameworks mit den man ebenfalls seine Klassendefinitionen strukturiert verfassen kann. Aber auch hier habe ich noch keine Variante gefunden bei der man auf dem ersten Blick sieht wo was angegeben und deklariert wird. (Was zwangsläufig zu Missverständnissen und Fehlern führt)
Ich will das mal demonstrieren an der Kompaktschreibweise, die Kommentare habe ich mal absichtlich weggelassen.

  
var Chicken = Y.extend(  
    function (name) {  
        Chicken.superclass.constructor.call(this, name);  
        this.run();  
    },  
    Bird,  
    {  
        this.name = 'test',  
        run: function () {  
            this.sing();  
        },  
        sing : function () {  
            alert("The chicken " + this.name + " says:");  
            Chicken.superclass.sing.call(this, name);  
        }  
    }  
);  

Wer mir hier auf Anhieb sagen kann was hier was zu bedeuten hat, verdient meinen Respekt. Aber der kann mir sicherlich auch erklären warum die Argumentreihenfolge gerade Konstruktor, Elternkonstruktor und dann Members ist. Gut man kann argumentieren in Java schreibt man auch Klasse extends Elternklasse und dann kommt der Klassenrumpf aber man könnte genau anders herum argumentieren, das man in JS üblich erst die Klasse definiert und anschließend die Elternklasse als Prototype setzt.
Ich habe mich im ersten Moment auch über das erste Argument gewundert. Was hat da ein Funktion zu suchen ich will doch von einer bestehenden Klasse Extenden und nicht eine neue definieren. Und was mache ich wenn ich von keiner Klasse erbe? muss ich dann als zweites Argument null angeben oder darf man das weg lassen. Ich wüsste es nicht also erstmal nachschlagen.

Nun worauf ich hinaus will Struktur ist in großen Projekten alles!

Zum Vergleich das selbe mit meinem Framework:

  
Bird.extend(function (super) {  
    public.name = 'test';  
    public.init = function(name) {  
        super(this, name);  
        this.run();  
    }  
    public.sing = function(name) {  
        alert("The chicken " + this.name + " says:");  
        super.sing(name);  
    }  
});  

Nun über sein eigens Werk zu Urteilen ist immer schwer, aber wem schon einmal Klassen in einer typischen OO Programmiersprache über den Weg gelaufen sind, ...

Ich sehe das nicht als Fehler von JavaScript. Ich bin nicht der Ansicht, dass die grundlegendsten Strukturen bereits »sicher« sein sollten... . Bei JavaScript ist es Aufgabe des Programmierers, sich selbst Strukturen zu schaffen...

Hm hier schieden sich wohl die Geister warum muss der Programmierer sich selbst Strukturen schaffen?

Wenn das jeder tun würde und man mit mehreren Leuten an einem Projekt arbeitet, was gibt denn das für ein Wust...

Genau hierfür sind Frameworks da, eine gemeinsame Struktur schaffen auf die man sich einigt. Sie ist generisch und für Neueinsteiger verständlich.

Und wenn man OO Programmierung in JS betreiben will dann kommt man um ein Umfangreicheres Framework nicht darum herum. Wenn man jedoch JS Funktional angeht sieht die Sache ganz anders aus.

So ist ein bisschen länger geworden aber ich komm leider nur Abends dazu meinen Senf dazu zu geben.

Grüße Flo