Manöverkritik zu Einsteiger-Tutorial OOP in JS

[Felix Riesterer]

Liebe Mitlesende,

wir hatten noch kein Tutorial, das sich mit der Erzeugung von Objekten und insbesondere mit der class-Syntax intensiver beschäftigt. Da ich für meinen Informatikunterricht etwas in dieser Art gebrauchen könnte (und etwas ähnliches schon erstellt hatte), habe ich das nun im Wiki ergänzt (Platz war ja schon dafür reserviert worden).

Was würdet ihr verbessern oder anders vorschlagen?

Liebe Grüße

Felix Riesterer

[Matthias Scharwies]

Servus!

Liebe Mitlesende,

wir hatten noch kein Tutorial, [...] habe ich das nun im Wiki ergänzt…

Ja, cool - da schaut man mal 24h nicht rein und schon gibt's was Neues!

Vielen Dank!

Was würdet ihr verbessern oder anders vorschlagen?

Ich les es mir später durch! Versprochen!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Felix,

ich find's gut, dass Du da ran willst.

Den Einstieg finde ich allerdings... befremdlich. Du möchtest OOP erklären und fängst damit an, dass Funktionen Objekte sind und man sie als Parameter übergeben kann.

Ist das ein guter Einstieg? Bisher hast Du mehr auch noch nicht online - oder finde ich das nur nicht?

Sollte man nicht erstmal formal erklären, was die Idee eines Objekts ist? Die Begriffe "Eigenschaft" und "Methode" einführen? Nicht in aller Ausführlichkeit und mit allen JS-Besonderheiten, aber die Konzepte sollte man erklären. Ich hatte damit mal begonnen, bin aber stecken geblieben und mein Text erklärt auch zu viel für ein Einstiegstutorial. Vielleicht nützt er Dir etwas. Vielleicht ist er didaktisch auch untauglich.

Danach könnte man auf in JS eingebaute Objekte eingehen. Aber nicht Function, das ist zu abstrakt. Lieber String und Number. Da kann man ein paar Eigenschaften und Methoden vorstellen. Man könnte auch "Objekt", "Eigenschaft" und "Methode" an Hand von Strings einführen. length ist eine Eigenschaft des Strings. Und ich würde in diesem Moment noch lügen und erklären, dass substr eine Methode des Strings sei. Dass "Hallo Welt" die substr-Methode über die Prototypenkette aus dem String.prototype Objekt übernimmt, ist jetzt noch zu kompliziert. Man kann andeuten, dass die Wahrheit komplizierter ist, aber noch nicht drauf eingehen.

Als nächstes kann man eigene Objekte erzeugen. Aber nicht mit class oder new Foo(), sondern als Literal, so wie im Objekte-Exkurs des JS-Anfangstutorials. Bei der Gelegenheit bietet es sich an, die Objektnatur von Funktionen zu beschreiben und zu erklären, dass Methoden nichts weiter sind als Eigenschaften, deren Wert eine Funktion ist. Was die Erwähnung von this nach sich zieht - aber mit Bedacht, Closures machen den Leser jetzt noch verrückt. Man kann die alte und neue Syntax beschreiben, die in einem Objektliteral eine Methode bereitstellt. Man kann getter und setter (mit der neuen Syntax) vorstellen. Was es in dem Zusammenhang mit Property-Descriptoren auf sich hat, was der Unterschied zwischen data- und accessor-descriptors ist, das kann man in einem Extrakapitel für besonders Interessierte hintenanstellen. Und was ist mit Klassen? Nix!

Und dann kann man erklären, was ein Prototyp ist, wie die Prototypenvererbung funktioniert und zeigen, wie man mit Object.create einem Objekt einen Prototypen gibt. Klassen? Nada!

Als nächstes kann man auf das Konzept der Konstruktorfunktion mit ihrem prototype-Property eingehen. Man kann erklären, dass hiermit das aus anderen Sprachen bekannte Klassenkonzept nachgebildet werden kann, und sollte den Begriff der Klasse vielleicht auch etwas genauer erläutern, um ihn vom Prototypen abzugrenzen.

Und nachdem das alles bekannt ist, könnte man das class-Schlüsselwort als Syntaxzucker für all das beschreiben.

Und dann geht's an das Eingemachte: Vererbung. Klassenvererbung vs Prototypvererbung. Was tut super() eigentlich, wenn man es im Konstruktor aufruft? Überschriebene Methoden. Der Unterschied - in der Klassenwelt - zwischen normalen und virtuellen Methoden, und der Umstand, dass in JS alle Methoden virtuell sind.

Und dann die OOP-Welt. Modellierung, Beziehungen (Vererbung, Assoziation, Aggregation), einfache Patterns, Delegation, Polymorphie. Das kann aber nur ein Ausblick sein, hier muss man wohl auf die Literatur verweisen.

Man muss auch schauen, wo sich das Tutorial von den Texten unter "Umgang mit Objekten" abgrenzt. Wo man bewusst zu wenig erklärt und auf weiterführende Abschnitte an anderen Stellen verweist.

Rolf

[Der Martin]

Hallo,

Sollte man nicht erstmal formal erklären, was die Idee eines Objekts ist? Die Begriffe "Eigenschaft" und "Methode" einführen?

und in dem Zusammenhand vor allem auch erklären, was der grundlegende Vorteil von OOP ist. Es gibt nämlich sehr viele Programmierer und Softwareentwickler (Amateure ebenso wie Profis), die bisher nur die traditionelle prozedurale Programmierung gewöhnt sind und sich bei OOP-Konzepten fragen: Warum sollte ich das so umständlich machen?
Ein bisschen zähle ich mich sogar auch dazu, kommt auf den konkreten Fall an.

Nicht in aller Ausführlichkeit und mit allen JS-Besonderheiten, aber die Konzepte sollte man erklären. Ich hatte damit mal begonnen, bin aber stecken geblieben und mein Text erklärt auch zu viel für ein Einstiegstutorial.

Ich finde auch deinen Ansatz gut, weil er am Anfang kurz den Sinn und Zweck umreißt und dann von einfachen zu immer komplexeren Sachverhalten geht. Aber vielleicht sollte man den ganzen Artikel in Abschnitte zerschneiden, damit man als Leser kleine, abgeschlossene Sinneinheiten vorfindet, die man auch in überschaubarer Zeit lesen und verstehen kann.

Und dann die OOP-Welt. Modellierung, Beziehungen (Vererbung, Assoziation, Aggregation), einfache Patterns, Delegation, Polymorphie. Das kann aber nur ein Ausblick sein, hier muss man wohl auf die Literatur verweisen.

Oder zumindest mal ein Beispiel skizzieren, in dem OOP ein echter Mehrwert ist. Die Beispiele, die meist zur Erläuterung bestimmter Features hergenommen werden, sind oft entweder an den Haaren herbeigezogen, oder sie provozieren tatsächlich die Reaktion: Aber das geht doch viel einfacher.

Live long and pros healthy,
 Martin

[Felix Riesterer]

Lieber Martin,

und in dem Zusammenhand vor allem auch erklären, was der grundlegende Vorteil von OOP ist.

darauf wollte ich nur verlinken, weil ich den Verdacht habe, dass das im Wiki schon an mehreren Stellen stehen müsste. Aber ja, diese Frage sollte dort zumindest stehen und ihre Antwort zumindest verlinkt sein.

Es gibt nämlich sehr viele Programmierer und Softwareentwickler (Amateure ebenso wie Profis), die bisher nur die traditionelle prozedurale Programmierung gewöhnt sind und sich bei OOP-Konzepten fragen: Warum sollte ich das so umständlich machen?

Das ist in der Tat richtig.

Ich finde auch deinen Ansatz gut, weil er am Anfang kurz den Sinn und Zweck umreißt und dann von einfachen zu immer komplexeren Sachverhalten geht. Aber vielleicht sollte man den ganzen Artikel in Abschnitte zerschneiden, damit man als Leser kleine, abgeschlossene Sinneinheiten vorfindet, die man auch in überschaubarer Zeit lesen und verstehen kann.

Das sehe ich genau so.

Oder zumindest mal ein Beispiel skizzieren, in dem OOP ein echter Mehrwert ist. Die Beispiele, die meist zur Erläuterung bestimmter Features hergenommen werden, sind oft entweder an den Haaren herbeigezogen, oder sie provozieren tatsächlich die Reaktion: Aber das geht doch viel einfacher.

Ist mein Person-Objekt dafür nicht gut?

Liebe Grüße

Felix Riesterer

[Der Martin]

Hallo Felix,

Oder zumindest mal ein Beispiel skizzieren, in dem OOP ein echter Mehrwert ist. Die Beispiele, die meist zur Erläuterung bestimmter Features hergenommen werden, sind oft entweder an den Haaren herbeigezogen, oder sie provozieren tatsächlich die Reaktion: Aber das geht doch viel einfacher.

Ist mein Person-Objekt dafür nicht gut?

es ist ein guter Ansatz, aber noch zu abstrakt oder zu minimalistisch, um den Einsatz wirklich sinnvoll und praxistauglich zu demonstrieren. Der Klassiker wäre ein GUI-Framework, auch wenn das als Beispiel viel zu komplex wäre (es sei denn, man möchte wirklich nur das Konzept anreißen, ohne auf Details einzugehen). Die verfolgen nämlich oft den Ansatz: Jedes auf dem Bildschirm dargestellte Objekt ist auch als Objekt modelliert, mit all seinen Eigenschaften und Methoden. Mit Vererbung, Polymorphie und der Erweiterung von Klassen.
Das Windows-GUI ist zum Beispiel hochgradig objektorientiert, obwohl es AFAIK in einer Mischung aus C und ein bisschen Assembler programmiert ist (zumindest war das früher mal so). Also Sprachen, die man nicht direkt mit OOP in Verbindung bringt und die das nicht direkt durch Sprachmerkmale unterstützen.

Was aber auch wieder zeigt: OOP ist vor allem ein Denkansatz. Dass die verwendete Sprache das konkret unterstützt (wie etwa Java, Javascript, C++ oder Python), ist "nice to have", aber nicht Bedingung.

Live long and pros healthy,
 Martin

[Felix Riesterer]

Lieber Rolf,

ich merke, dass hier ein Fachmann mit Jahren an Erfahrung mit JavaScript spricht. Daher siehst Du die ganzen Aspekte des Themas in einem völlig anderen Licht, als ein Anfänger.

Ich erlebe immer wieder in Diskussionen über meine Anfänger-Tutorials, wie man meine Vereinfachung (didaktische Reduktion) als problematisch diskutiert. Das merke ich indirekt bei Dir daran, dass Du mit der prototypischen Objektorientierung argumentierst. Wenn man einen Anfänger aber an Objektorientierung heranführen will, sollte der doch möglichst bald die class-Syntax verwenden, findest Du nicht? Vor allem, wenn er auch noch mit PHP experimentiert, wo es die fast identische Schreibweise ja auch gibt! Und wie kommt man am schnellsten zu dieser Syntax?

Ich habe schon eine Weile überlegt, ob ich die Sache mit der prototypischen Wirklichkeit hinter der class-Syntax in ein nachgelagertes Kapitel einbringen will. Aber was soll ein Anfänger damit? Und oft kommen die hier im Forum mit gecopy-pastetem Code, wo man fragen muss, wo sie den her haben, weil er vielleicht noch ältere Konzepte in sich trägt, weshalb ich dachte, die Sache mit den Funktionen als Konstruktoren ohne class-Syntax unbedingt mit einfließen zu lassen - ohne Prototypen-Kette.

Den Einstieg finde ich allerdings... befremdlich. Du möchtest OOP erklären und fängst damit an, dass Funktionen Objekte sind und man sie als Parameter übergeben kann.

Anfänger hantieren erstaunlich früh mit Funktionen. Das kennen sie. Dass man die als Objekte verstehen kann, ohne ein genaues Verständnis davon zu haben, was Objekte in JavaScript überhaupt sind, wird wenigstens dadurch erreicht, dass man sie als Parameter übergeben kann. In PHP war das z.B. lange nicht möglich, da musste man allen Ernstes den Funktionsnamen als String übergeben, aber in JavaScript ist das schon seit Urzeiten möglich. Das hat mich als Anfänger damals sehr verblüfft, dass das in JS "so einfach" ging und in PHP (Version 4.x) nicht.

Ist das ein guter Einstieg? Bisher hast Du mehr auch noch nicht online - oder finde ich das nur nicht?

Woran bemisst Du "gut"? Für den Anfänger ist wichtig, dass er das Geschriebene nachvollziehen kann. Und wenn ich noch überhaupt nicht weiß, was ein Objekt eigentlich ist, dann ist das zumindest etwas Praktikables für ein erstes Beispiel. Und es dient auch dem Zweck, das Hinzufügen von Methoden von der Schreibweise her vorzuentlasten.

Sollte man nicht erstmal formal erklären, was die Idee eines Objekts ist?

Das ist die uralte und hier immer wieder neu aufflammende Frage, wie man einen Anfänger am besten da abholt, wo er steht. Mein Ansatz ist da jedes Mal der, dass ich mit etwas beginne, womit der Anfänger einigermaßen schon vertraut ist, um es zu entwickeln und in neue Zusammenhänge zu setzen.

Aber es mag auch andere Lerntypen geben, die gerne erst eine theoretische Betrachtung haben wollen. Das ist auch in Ordnung. Die dürfen dann zu Orlok gehen. Der macht das super.

Ich denke mit Schaudern an den Baby-Vorbereitungskurs, bei dem wir angehenden Eltern über sechs Zeitstunden lang (nein, kein Scherz, leider nicht!) mit Infos vollgepumpt wurden ehe wir an einer Baby-Puppe das Wickeln üben durften. So gehe ich nicht vor und empfehle es auch niemand anderem.

Die Frage "Was ist eigentlich ein Objekt?" stelle ich auf der Einführungsseite. Nicht gleich als erstes, aber ich stelle sie. Danach geht es dann zu Eigenschaften und Methoden.

Die Begriffe "Eigenschaft" und "Methode" einführen? Nicht in aller Ausführlichkeit und mit allen JS-Besonderheiten, aber die Konzepte sollte man erklären.

Da fand ich das Beispiel anhand von komplexen Datentypen ganz zielführend. Du nicht? Eine Geo-Koordinate hat... zwei Eigenschaften.

Ich hatte damit mal begonnen, bin aber stecken geblieben und mein Text erklärt auch zu viel für ein Einstiegstutorial.

Ich habe es mir angesehen und stimme Dir zu. Die Sache mit den Voraussetzungen, damit man mit dem Punktoperator arbeiten kann, finde ich prinzipiell sehr gut und wichtig, aber ab wann kommt ein Anfänger bei den gegebenen Beispielen auf die Idee, einen Namen für eine Eigenschaft mit Leer- oder Sonderzeichen zu schreiben? In dem Fall ist man meiner Meinung nach schon wieder jenseits eines reinen Anfänger-Tutorials.

Vielleicht nützt er Dir etwas. Vielleicht ist er didaktisch auch untauglich.

Für mich als ewig Lernenden nützt er auf jeden Fall! Dafür vielen Dank! Als Ideengrube für mein Tutorial finde ich ihn zu ausführlich. Er geht in Richtung eierlegende Wollmilchsau. Das versuche ich zu vermeiden.

Danach könnte man auf in JS eingebaute Objekte eingehen. Aber nicht Function, das ist zu abstrakt.

Hehe. Auf in JavaScript eingebaute Objekte gehe ich absichtlich nicht ein, weil das den Rahmen sprengen würde. Die Sache mit function habe ich ja oben schon erläutert.

Lieber String und Number.

Ah! Auf primitives bin ich auch absichtlich (noch?) nicht eingegangen. Das wäre in der Tat ein Feld, das dem Artikel bisher fehlt.

Als nächstes kann man eigene Objekte erzeugen. Aber nicht mit class oder new Foo(), sondern als Literal, so wie im Objekte-Exkurs des JS-Anfangstutorials.

Das kommt meiner Meinung nach darauf an, was man damit erreichen möchte. Daher habe ich auch die Hinweise ergänzt, wann man besser welche Schreibweise nimmt. {} eignet sich meiner Meinung nach besser für Singletons. Will ich mehrere Instanzen haben, lohnt eine Klasse. Für mein Projekt, in dem ich eine PWA baue, verwende ich selbst für den Client eine class, obwohl der ein Singleton ist.

Bei der Gelegenheit bietet es sich an, die Objektnatur von Funktionen zu beschreiben und zu erklären, dass Methoden nichts weiter sind als Eigenschaften, deren Wert eine Funktion ist.

Warum nennt man sie dann so? Aber ja, "Eigenschaften, deren Wert eine Funktion ist" finde ich sehr gut! Das sollte ich so übernehmen.

Und nachdem das alles bekannt ist, könnte man das class-Schlüsselwort als Syntaxzucker für all das beschreiben.

Geht das nicht ein bisschen in die Richtung: Also den USB-Stick darfst Du erst verwenden, wenn Du mit der 5¼"-Floppy das Abspeichern (unter DOS versteht sich!) gelernt hast.

Ich bin ja froh, dass es endlich diese class-Syntax gibt! Und was spricht gegen ihre sofortige Verwendung? Wo sind die Fallstricke für den Programmierer, wenn er sich dabei der Prototypen-Kette nicht bewusst ist?

Und dann geht's an das Eingemachte: Vererbung. Klassenvererbung vs Prototypvererbung. Was tut super() eigentlich, wenn man es im Konstruktor aufruft? Überschriebene Methoden. Der Unterschied - in der Klassenwelt - zwischen normalen und virtuellen Methoden, und der Umstand, dass in JS alle Methoden virtuell sind.

Da kenne ich mich selbst noch zu wenig aus. Da lerne ich auch erst noch dazu. Mir ist klar, dass jede Klasse eine Konstruktor-Methode haben muss. Und mir ist auch klar, dass eine erbende Klasse ihre eigene Konstruktor-Methode definieren kann, was die Frage aufwirft, was aus der Konstruktor-Methode der Elternklasse wird, wenn ein Objekt neu instanziiert wird. Dazu komme ich vielleicht auch irgendwann. Mit der Prototypen-Kette habe ich auch Jahre gebraucht, bis ich mich einigermaßen sicher genug gefühlt hatte, dieses Konzept tatkräftig anzugehen.

Und dann die OOP-Welt. Modellierung, Beziehungen (Vererbung, Assoziation, Aggregation), einfache Patterns, Delegation, Polymorphie. Das kann aber nur ein Ausblick sein, hier muss man wohl auf die Literatur verweisen.

Dein Ehrgeiz gefällt mir! :-)

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

das wird mir jetzt zu umfangreich, um viel dazu zu schreiben. Ist wohl auch nicht nötig, du hast Deine Ideen und sie sind anders als meine. Als Lehrer hast Du da professionelle Vorteile in der Wissensvermittlung. Als Programmierer habe ich vielleicht professionelle Vorteile in der Webentwicklung 😉. Und deine Vorteile sind für den Zweck die relevanteren.

Ich habe auch nur die erste Seite deiner Texte gesehen. Irgendwie hat, als ich da vorher war, die Verlinkung zum nächsten Abschnitt nicht funktioniert. Jetzt ist es ok.

Ich möchte nur auf einen deiner Punkte eingehen, und warte im übrigen ab, wie sich dein Tutorial entwickelt. Sagst Du Bescheid, wenn es fertig ist?

class - Wo sind die Fallstricke für den Programmierer, wenn er sich dabei der Prototypen-Kette nicht bewusst ist?

Ich erinnere mich an meine ersten Gehversuche mit OOP. Borland C++, in den 80er Jahren. Ich habe ewig mit dem Debugger über den internen Abläufen gehangen, um zu verstehen, was da eigentlich passiert. Um zu begreifen, was virtuelle Methoden eigentlich sind. Ich möchte wissen, was unter der Haube passiert. Außer beim Auto. Da kapiere ich das eh nicht 😂

Wer auf hohem Abstraktionsniveau herumturnt, scheitert in dem Moment, wo das von der Abstraktion vorgegebene Modell seine Grenzen erreicht. Oder wo das Modell falsche Freunde vorzeigt - JS-OOP ist eben nicht Klassen-, sondern Prototypbasierend. Die class-Syntax simuliert eine klassenorientierte OOP, ist aber keine. Klassen werden zur Compilezeit definiert und sind zur Laufzeit unveränderlich. Verändert man einen Prototypen, wird das in allen Objekten sofort sichtbar, die ihn benutzen. Bei Prototypen spricht man aus gutem Grund von "klassenloser OOP".

Ich bin mir im Moment keiner Fallstricke bewusst. Es mag aber welche geben, wenn man z.B. nicht weiß, dass die mit this.wert = 17 erzeugten Eigenschaften am Objekt gespeichert sind, aber Methoden, getter und setter am Prototypen landen. Wenn Vererbung ins Spiel kommt, wird es noch subtiler. In einem Klassenkonstrukt kann ich Eigenschaftsdefinitionen in einer Subklasse überschreiben. Die Eigenschaft ist in der Subklasse aber nach wie vor vorhanden und kann - je nach Sprache - auch benutzt werden. In JS liegen alle Eigenschaften am Objekt. Wenn die Superklasse this.foo=3; setzt und die Subklasse danach this.foo=7;, dann ist das das gleiche foo. Methoden der Superklasse sehen danach die 7. In C++ könnte ich in der Subklasse das foo der Superklasse überlagern. PHP verhält sich unterschiedlich, je nach dem, ob die Eigenschaft in der Superklasse private ist oder nicht (ARGHH!).

Es ist didaktisch vermutlich ganz elegant, mit der class-Syntax loszulegen. Aber irgendwann muss man auch an's Eingemachte und erklären, wie die Vererbung in JS tickt. Du hast schon recht, das kann man später tun.

Rolf

[Henry]

Hallo Felix,

gute Tutorials anfängergeeignet zu schreiben, ist an sich schon mal schwierig. Ich erinnere mich an meine ersten PHP-Bücher und wollte schon aufgeben, weil ich nahezu nichts verstanden hatte. Vie zu viele Fachwörter, viel zu viel vorausgesetzt,usw. Klar ein Erfahrener macht sich keine Gedanken mehr darüber, was ein Punkt oder Semikolon bei einem String bedeutet, ein Neuling schon.

Aber gut die Frage ist natürlich was bedeutet Anfänger, grundsätzlich ganz neu in der Materie und nur Neuling in diesem speziellen Ansatz. Bei OOP kann man ruhig schon Grundwissen voraussetzen, ohne je mit Klassen gearbeitet zu haben. Dennoch sind manchmal auch für Nicht-Neulinge kindgerechte Beispiele ein AHA-Erlebnis. Mal ein Beispiel, das ist mir jetzt eigentlich schon zu ausladenend aber prinzipiell find ich die Erklärung gut.

Ohne zu zitieren erwähntest du verschiedene Typen von Lernenden, ja ist schon so, aber ich glaube zu Anfang unterscheiden sich alle nicht darin möglichst schnell ein Erfolgserlebnis zu haben. Daher, was ich bisher noch nie bei OOP Tutorials gesehen habe, sind Gegenüberstellungen von einfachen plausiblen Beispielen ohne und mit OOP.

Aber bleib bitte am Ball, ein gutes OOP- Tutorial hier wäre nicht schlecht.

Gruss
Henry

[Der Martin]

Hallo Henry,

gute Tutorials anfängergeeignet zu schreiben, ist an sich schon mal schwierig. Ich erinnere mich an meine ersten PHP-Bücher und wollte schon aufgeben, weil ich nahezu nichts verstanden hatte. Vie zu viele Fachwörter, viel zu viel vorausgesetzt,usw.

ein klassisches Gebiet für diese Art von Kritik sind Kochbücher. Ja, inzwischen gibt es tatsächlich auch Kochbücher, die auf den Kenntnisstand "Null" von Küchen-Legasthenikern zugeschnitten sind. Aber meistens werden eine ganze Menge Vorgänge und Verfahren einfach vorausgesetzt: Blanchieren? Was ist das? Anschwitzen? Hä? Zum Schluss noch abschmecken? Ja, womit denn, bitte?

Klar ein Erfahrener macht sich keine Gedanken mehr darüber, was ein Punkt oder Semikolon bei einem String bedeutet, ein Neuling schon.

Eben. Eine gestandene Hausfrau denkt über die genannten Beispiele gar nicht nach. Aber ein Laie? - Zum Beispiel ein 25jähriger Single, der bis eben noch die Annehmlichkeiten von Hotel Mama genossen hat, und jetzt für sich selbst sorgen soll.

Bei OOP kann man ruhig schon Grundwissen voraussetzen

Ja, aber dieses Grundwissen ist bei jedem ein bisschen anders gelagert.

Ohne zu zitieren erwähntest du verschiedene Typen von Lernenden, ja ist schon so, aber ich glaube zu Anfang unterscheiden sich alle nicht darin möglichst schnell ein Erfolgserlebnis zu haben.

Doch, ich. ;-)

Bevor ich auch nur anfangen mag, selbst zu probieren, möchte ich erst einen möglichst großen Teil der Theorie verstanden haben. Einfach nur probieren, Beispiele nachbauen und damit spielen, ohne wirklich zu verstehen, was ich da mache, finde ich zutiefst unbefriedigend.

Live long and pros healthy,
 Martin

[Matthias Scharwies]

Servus!

Hallo Felix,

ich find's gut, dass Du da ran willst.

Ich auch!

[…]

Man muss auch schauen, wo sich das Tutorial von den Texten unter "Umgang mit Objekten" abgrenzt. Wo man bewusst zu wenig erklärt und auf weiterführende Abschnitte an anderen Stellen verweist.

Die sechs Einzel-Artikel zum Umgang mit Objekten sind ja von @molily ca. 2006 geschrieben und von mir an die JavaScript/Sprachelemente gehängt worden. Diese sind mittlerweile so umfangreich, dass sie imho nicht als Kurs gelesen werden können.

Auch Umgang mit Objekten ist eben kein Kurs/Tutorial:

• JavaScript/Objekte/Eigenschaften_und_Methoden ist ja von mir auch schon mal erfolglos angepackt worden.
• Die Objektabfragen sind heute imho Standard, damals musste man die Leute erst von den Browserabfragen wegbringen.

Ein Kurs über OOP, der auf den zwei Anfängerkursen "Einstieg in JavaScript und "Das DOM und Einbindung in HTML aufbaut, schließt da wirklich eine Lücke für den ambitionieren Anfänger.

• Wenn er ES6 wie let und const , die Pfeilfunktion und class verwendet, gut!
• Wenn er auf dem vorhandenen Wissen aus der Schule aufbaut, wo Klassen und Objekte schon mal erwähnt wurden, gut.
• Wenn das Tutorial langfristig den "Umgang mit Objekten" integriert, um so besser.

Zusätzlich gibt es noch: JavaScript/Objekte/Object von Orlok.

Herzliche Grüße

Matthias Scharwies

[asdf]

Hi,

ich habe lange mit mir gerungen, ich möchte dir Kritik dalassen.

Meiner Meinung werden die besten Konzepte unabhängig von Details erklärt. Mit dem größeren Bild und dem Verständnis für das grössere Bild lassen sich dann verschiedenste Syntaxe, Sprachen, etc verstehen und mit Übung beherrschen.

Ab ins Detail:

Du leitest in ein Tutorial wie sich OOP innerhalb von javascript darstellt. Könnte es hier hilfreich sein, vorrausgehend einmal OOP kurz zusammenzufassen und DANN auf die Eigenarten von javascript einzugehen?

Innerhalb von "Alles ist ein Objekt" (https://de.wikipedia.org/wiki/Objektorientierte_Programmierung / Definition / Kay / Everything is an object) leitest du von prozeduralem Programmieren ein.

"In JavaScript gilt der Grundsatz, dass alles ein Objekt ist. Wenn wir z.B. eine Funktion definieren, dann ist die Funktion ein function-Objekt. Das macht es möglich, eine Funktion als Parameter an eine andere Funktion zu übergeben:"

Ich denke, der eigentliche Grund dafür liegt hier: https://de.wikipedia.org/wiki/Funktion_h%C3%B6herer_Ordnung

"Das Beispiel ist kaum praxistauglich," Dinge die geschrieben stehen, setzen sich fest. Kannst du eventuell anstatt des Beispiels ein praxistaugliches nehmen?

"Echte Anwendungsfälle sind die Ereignisbehandlung oder die zeitgesteuerte Ausführung von Funktionen (setInterval oder setTimeout), sowie das Konzept der Promises. "

Das sind imho ablenkende Details, die mit OO/OOP nichts zu tun haben. Warum den Leser mit Irrelevantem Ablenken?

"Funktionsdefinitionen": Du leitest ganz oben mit "Es baut auf den beiden Tutorials Grundlagen der Programmierung und Grundlagen des DOM auf. " ein, jetzt definierst du Funktionen; Die sind oben bereits wissenstechnisch vorrausgesetzt. Warum?

Auch dort finden sich imho wieder ablenkende Dinge wie "Das Schlüsselwort const ist im Sprachstandard ECMA 6 eingeführt worden", ... Was hilft das dem Leser OO/OOP zu verstehen?

...

Dieses Theme setzt zieht sich weiter in den Kapiteln durch. Kannst du dich und die Beispiel auf das Wesentliche beschränken, was OO/OOP erklärt?

"Was ist eigentlich ein Objekt?" Für mich unvollständig, wenn man z.B. Kay nimmt: "“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.” würde ich hier erwarten, dass alle diese Dinge kurz beschrieben werden, und später in Unterkapiteln erklärt und dann im Kontext von javascript dargestellt werden.

"Komplexe Datentypen" Du beginnst hier mit dem Bild des Punktes auf der Erde. Kannst du diese "Geschichte" als roten Faden durch die anderen Kapitel/Beispiele führen (Im nächsten Kapitel geht es um "Personen" und nicht mehr um "Punkte"). Gibt es vielleicht einen anderen konsistenten, roten Beispielfaden?

"Methoden" der hier relevante Teil, der meines Erachtens zu kurz kommt, ist "this". Der zentrale Unterschied zwischen function und method ist doch, dass eine Methode nur im Kontext von Zustand (State = Objekinstanz = this) benutzbar ist? Auch hier finde ich, für mich, wieder verwirrende Zwischeninfos, z.B. "(doch, im Kontext von window und kann mit window.f() aufgerufen werden)".

"Objektliterale": -> "Schreibweise eines Objektliterals war übrigens die Grundlage für das mittlerweile im Internet sehr verbreitete JSON-Format." OO/OOP? Wichtig oder Ablenkung vom eigentlichen Thema?

...

Ich würde wie folgt vorgehen:

1. Grosses Bild (OO), frei von javascript
2. Vorraussetzungen (was muss ich verstanden haben, damit ich das Tutorial verstehe?)
3. Einzelne Kapitel:

• Definition mit Lebensechtem, code-freiem Beispiel
• Umsetzung der Beispiele konkret mit Javascript, Positive Beispiele (also solche, wo nicht "aber eigentlich macht man es so nicht" dransteht)

4. Weitere Detailinfos als eigenes Kapitel, z.B. "Did you know, that JSON ...". Hier hat man sich entweder die notwendigen Kontexte erarbeitet und liest das Kapitel nicht.

Nichtsdestotrotz weiss ich, dass es sehr schwierig ist, solche Inhalte zu vermitteln, deswegen hast Du meinen grössten Respekt für den jetzigen Inhalt!

gruss

ps: als Inspiration: https://quantum.country/qcvc - gerade in Bezug auf "roter Faden"

[Felix Riesterer]

Liebe Kritiker,

vielen Dank für die bisherige Kritik! Mir ist klar, dass ich das Thema kaum "richtig" im Sinne der Ingenieurswissenschaft vermitteln kann, weil ich es selbst zu wenig durchdringe. Mein Ansatz ist der, was ein Anfänger tatsächlich schon verstehen kann. Alle die hier kritisieren, sind keine Anfänger mehr. Und leider meldet sich keiner, der aus der echten Anfängersicht eine Kritik da lassen könnte.

Aber das Problem haben wir hier eigentlich schon bei jedem anderen Anfängertutorial gehabt, dass die eigentliche Zielgruppe sich nicht zu Wort meldet.

Liebe Grüße

Felix Riesterer