[HOW-TO/TUTORIAL] Gutes JS OOP Tutorial oder Buch gesucht

[tsseh]

Funktionen sind in JS also die einzigste "Wirkungsvolle" Möglichkeit, einen separaten Scope zu eröffnen?

bis es6

Das würde ja dafür sprechen, möglichst viel über Konstruktoren zu machen. Oder eben in den Methoden eines Objektes.

deswegen nutzt man auf globaler ebene ja auch meist ein konstrukt wie

(function()
{
  // code
})()

Das let aus ES6 würde auch schon in einem normalen Anweisungsblock { } "Gefangen" werden, verstehe ich das richtig?

ja

Wenn ich das richtig verstehe, habe ich 2 Möglichkeiten:

1. Ich arbeite mit den Konstruktorfunktionen, erzeuge mit var obj1 = new Constructor1 das Objekt und baue auch die Prototypenkette auf.

2. Oder ich erzeuge direkt ein object (entweder per Literal oder new Object).
Und dann befülle ich das Objekt mit Methoden und Eigenschaften

der vorteil des konstruktors ist, du hast gleich eine funktion in der du private variablen und funktionen verstecken kannst.
sonst must du eine createXXXObject funktion nutzen.

Wenn ich das so mache, dann könnte ich mir ja den Aufwand mit der Prototypenkette komplett sparen und einfach selber gleich ein Objekt zusammenbauen wie ich es haben will?

ja

Wenn ich das richtig sehe, hat er bei dem voran gegangen Beispiel sogar einen Prototyp angegeben, obwohl ich ihn nicht selbst angegeben habe.

https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Object/create

 

[kkapsner]

konstruktoren und prototypen schließen sich ja bisher fast vollkommen aus, das ist ja das problem.

In wiefern? Ich benutze Konstruktoren zusammen mit Prototypen.

dort private methoden zu erzeugen

Das meinte ich mit "wenn's nicht sein muss"...

Aber ich verwende einen Konstruktor vor allem zum Initiaisieren und nicht um Methoden zu erzeugen.

auch sollte die property in beiden fällen auf ein und die selbe funktion zeigen, wenn das vernünftig optimiert ist

Die Funktionen sind aber nicht identisch, da der Scope anders ist... aber da kenn ich mich zu wenig aus. Ev. werden da die Scopes separat gespeichert...

dafür gibt es eigentlich keinen vernünftigen grund, im gegenteil ich finde das sogar gefählich.

Das ist Ansichtssache. Wenn du deine Ladereihenfolge sauber kontrollierst, ist es eine sehr gute Möglichkeit, Funktionalitäten zu erweitern. Im Grunde Mixins aber im Nachhinein. Ich würde das auch eher nicht für "Endbenutzerklassen" machen, aber für Framework- oder Utilityklassen finde ich das extrem hilfreich.

nenn mir mal einen usecase dafür

Fällt mir jetzt keiner ein, aber das ist eine Sache, die mit ES5 nicht geht. Das war auch nur mein Punkt.

 

[Darry]

Ja, über Object.create habe ich den Prototypen übergeben.

In einigen tutorials sieht man (in verbindung mit Konstruktorfunktionen) dass dass auf obj.prototype direkt zugeriffen wird und dort methoden oder eigenschaften oder andere objekte dem Prototypen zugewiesen werden werden.
Und anschließend wird noch der object constructor neu gesetzt.

Das finde ich etwas "unschön".

Das mit der Kapselung wäre aber ein vorteil der Konstruktorfunktionen.

Vielleicht kann man Konstuktorfunktionen verwenden, aber dennoch hauptsächlich mit Object.create arbeiten statt mit new und prototypen/construktorzuweisungen.

 

[tsseh]

In wiefern? Ich benutze Konstruktoren zusammen mit Prototypen.

weil es in der praxis so gut wie keine funktion gibt, die nicht auf private daten zugreifen muss.
mal sein mensch beispiel, da kannst du sagWas nicht als prototypfunktion implementieren ohne eine zusätzliche getVName funktion.
und eine getVName funktion ist zwar immer noch besser als eine public eigenschaft vname, aber auch die ist aus oop sicht nicht erwünscht und vermeidbar.

function mensch(vname)
{
  // var text = "";
  vname = vname || "unbekannt";
  this.sagWas = function(t)
  {
	  // text = t;
	  alert("Hallo, ich bin " + vname + " und sage " + t);
  };
}
var person01 = new mensch("Monika");
person01.sagWas("bla");
var person02 = new mensch("Franz");
person02.sagWas("Hallo");

- - - Aktualisiert - - -

Das mit der Kapselung wäre aber ein vorteil der Konstruktorfunktionen.

das würdest du ohne konstruktor ja auch nicht einfach so hinklatschen, sondern etwas wie

function createMensch(vname)
{
  vname = vname || "unbekannt";
  return {
    sagWas: function(t)
    {
      alert("Hallo, ich bin " + vname + " und sage " + t);
    }
  }
}
var person01 = createMensch("Monika");
person01.sagWas("bla");
var person02 = createMensch("Franz");
person02.sagWas("Hallo");

schreiben

 

[Darry]

Ich hab auch noch die Variante mit einem Object in einer self-invoking funktion gesehen um eine Kapselung ohne Konstruktorfunktion zu erreichen.

Wenn ich mir im Netz verschiedene Codebeispiele ansehe (von echten Projekten, und nicht die Tutorial snippets), scheint die Konstruktorschreibweise aber immer noch die bevorzugte Variante zu sein.

Wobei die dann die "Kaskadierung" auch gerne über call machen und einfach den Elternkonstruktor mit aufrufen und this nach oben durchreichen.
Alle Methoden und Eigenschaften landen dann direkt im neu konstruierten Objekt, als wenn man alle Konstruktoren einfach zusammenkopiert und dann ausgeführt hätte.

Eine "Referenzlösung" für mich hab ich bislang noch nicht ausbaldowert. Scheinbar ist es auch viel Geschmackssache oder Kontextabhängig wie man es macht.

Vielleicht fange ich auch einfach mal an, was eigenes zu programmieren und nicht nur Tutorials durchzukauen. Vielleicht ergibt es sich dann durch zunehmende Erfahrung von selber was man wo am besten nimmt.

LG

- - - Aktualisiert - - -

Hi.

Hier mal noch ein interessanter Link zu JS Patterns (Englisch) wo relativ viele Möglichkeiten gezeigt werden.

https://addyosmani.com/resources/essentialjsdesignpatterns/book/#revealingmodulepatternjavascript

Für mich war es hilfreich, auch wenn ich bei weitem noch nicht alle Patterns wirklich verstehe.

LG

 

[kkapsner]

Scheinbar ist es auch viel Geschmackssache oder Kontextabhängig wie man es macht.

Ja. Wobei ich der Meinung bin, dass die starke Diversität vor allem aus unterschiedlichen Geschmäckern geboren wird. In JS führen da viele Wege zum Ziel... und alle haben Vor- und Nachteile.

Vielleicht fange ich auch einfach mal an, was eigenes zu programmieren und nicht nur Tutorials durchzukauen.

Klingt nach einer guten Idee.