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

[Darry]

Zunächst einmal ein Hallo in die Runde, ich bin neu hier im Forum.
Ich mache Webdesign als Hobby. HTML, CSS und ein bisschen PHP Erfahrung ist vorhanden.
Mit JavaScript habe ich auch ein bisschen Erfahrung. Grundlagenwissen ist vorhanden, ich kann auch prozedural einfachere Sachen machen.

Ich suche ein gutes Tutorial für JavaScript, welches vor Allem das Thema OOP mit JavaScript behandelt.
Also Dinge wie z.B. Objekte, Prototypen, Konstuktoren, Scopes, Closures, Vererbung, this Kontext usw. Das sind nämlich die Dinge, wo ich noch nicht so ganz dahinter gestiegen bin.

Ich habe mit OOP auch noch keine Erfahrungen aus anderen Programmiersprachen. Ich habe bislang nur prozedural, vor Allem in PHP was gemacht.

Ich habe schon einige Tutorials und Webseiten dazu gelesen. Viele erklären zwar die Grundlagen gut, aber wenn es dann ans Thema OOP geht, lassen sie stark nach.

Ich habe grob gesagt 2 Sorten gefunden:
Viel viel Text im Grundlagenbereich (z.B. Variablen, Schleifen usw) aber OOP dann mit ein paar Zeilen "abgehandelt", als ob es für ein bisschen "Hobbywebdesign" sowieso nicht so wirklich gebraucht wird, oder als ob der Autor es selbst nicht gut erklären kann.

Oder die andere Variante:
OOP so kompliziert und ausufernd erklärt, dass man es ohne Informatik-Studium oder als Nicht-Nerd kaum versteht.


Am liebsten hätte ich sogar ein gedrucktes, gut verständliches Buch, dass ich erst 1-2 mal "einfach nur lese", bevor ich es dann aktiv mit Übungen durcharbeite. (Damit ich auch mal ohne am PC sitzen zu müssen, schonmal die ganzen Begrifflichkeiten verinnerlichen kann)


Was ich auch nicht so recht verstehe: Es gibt zum Beispiel mehrere Schreibwesen beu Funktionen und Objekten:

function Bla ();

oder

var bla = function();

oder

var bla = new function()


Auch bei Objekten gibt es verschriebene Schreibweisen:
var Object = new Object();

oder

var Object = {};


Da verstehe ich nicht, wann man und warum man eine bestimmte Schreibweise benutzt und wann eine andere.

Auch die Sache mit den Scopes und dem This sowie Prototypes und Vererbung ist für mich unglaublich schwer zu verstehen.


Ich hoffe, ihr könnt mir ein gut verständliches JS OOP tutorial und/oder ein Buch empfehlen.

 

[Darry]

Was haltet ihr eigentlich von folgendem Buch:

JavaScript: Grundlagen, Programmierung, Praxis - inkl. HTML5, JavaScript-Frameworks, jQuery, OOP (Galileo Computing) Gebundene Ausgabe – 24. Februar 2014
von Christian Wenz (Autor)


Ist da das Thema OOP mit Javascirpt gut und detailliert erklärt?

Alternativ käme auch folgendes Buch in Frage:

Einstieg in JavaScript (Galileo Computing) Broschiert – 28. Oktober 2013
von Thomas Theis (Autor)

 

[kkapsner]

Objekte, Prototypen, Konstuktoren, Scopes, Closures, Vererbung, this Kontext

Objekte, Prototypen, Konstruktoren und Vererbung sind Teil des OOP in JS, aber die anderen sind grundlegende Konzepte. Du kannst das also etwas getrennt lernen. V.A. Scopes und Closures verwendet man auch sehr viel bei prozeduraler/funktionaler Programmierung in JS.

function Bla ();

oder

var bla = function();

oder

var bla = new function()

Die ersten beiden haben wieder nichts mit OOP zu tun, sondern sind der Unterschied zwischen einer Funktionsdeklaration (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function ) und einem Funktionsausdruck (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/function ). Der Unterschied ist etwas schwer zu erklären, da die Unterschiede recht subtil sind - v.A. für einen Anfänger. Ich würde mir da erst mal nicht meinen Kopf drüber zerbrechen.

Das letzte ist etwas ganz anderes. Da wird eine anonyme Funktion als Konstruktor für ein Objekt verwendet. Das hat jetzt zwar was mit OOP zu tun, ist aber sehr unüblich. Oder meintest du new Function()? Das wäre dann der Konstuktor für ein Funktionsobjekt, was auch sehr unüblich und nicht zu empfehlen ist... aus den selben Gründen, warum auch eval schlecht ist.

var Object = new Object();

oder

var Object = {};

Diese beiden Schreibweisen sind völlig identisch. Nur ist die letzte kürzer und flexibler, da man direkt Eigenschaften definieren kann:

var a = {
	test: "hallo"
};
alert(a.test);

PS: Kann dir leider kein gutes Buch empfehlen. Hab' mir das selbst durch viel Stöbern im Netz und durch viel Ausprobieren beigebracht. Auch die beiden Bücher, die du erwähnt hast, kenne ich jetzt nicht...

 

[Darry]

Danke für Deine Antwort.

Welche Schreibweise für Funktionen würdest du denn empfehlen?
function foo();
oder
var foo = function();

In vielen Tutorials / Beipsielen wird beides gemischt verwendet aber kaum beschrieben warum.

Irgendwo habe ich ein Beispiel gelesen (Weiß nicht mehr wo, hab schon viel im Netz darüber rumgesurft)
Da war es so, dass bei einem Prototype und der Konstruktorfunktion die Schreibweise "function foo();" genutzt wurde, während für Methoden immer "var foo = function(); genutzt wurde.

In vielen OOP Beispielen wurde auch mit sogenannten Namespaces gearbeitet, die dann wie "Module" in anderen Programmiersprachen genutzt wurden.

Oder es wurde versucht das "Klassenkonzept" in JS nachzubilden. JS ist ja Prototypenbasiert, nicht klassenbasiert wie viele andere Programmiersprachen. Aber die haben versucht, dennoch das Klassenkonzept nachzubilden damit Leute mit Erfahrungen aus anderen OOP Programmiersprachen sich leichter tun.

Ich bin aber noch nicht "OOP Vorbelastet", ich kann also gerne auch das eigentliche Prototypenbasierte System lernen ohne die ganzen "Substitutionen" oder Nachahmen von Klassen usw.

Ansonsten will ich auch gleich auf ECMA-Script 5.1 bzw 6 im STRICT Mode einsteigen.
Internet Explorer 11 markiert bei mir das "Untere ende der Fahnenstange". Alles was älter ist, wird bei mir unter "Ferner liefen" verbucht.
Workarouns für ältere Browser und JS Versionen usw interessieren mich also nicht mehr.

Viele Tutorials sind leider schon etwas älter und nutzen noch alte Verfahren und Workarounds, und machen dadurch die Sache etwas komplizierter als sein müsste. Einiges ist in neueren JS Versionen ja vereinfacht wurden, vor Allem dadurch, dass gewisse Sachen nicht mehr "Umschrieben" werden müssen, sondern direkt im Sprachkern vorhanden sind.


Was das Buch betrifft:

Ich habe mit meinem Buchhändler gesprochen.

Von dem Buch "Einstieg in JavaScript", von Thomas Theis (Verlag Galileo Computing) ist am 26.02, also gestern, eine Neuauflage erschienen.

Das Buch ist, laut Internet-Bewertungen, auch etwas mehr an Leute ohne Vorwissen aus anderen Programmiersprachen gerichtet, als das Werk von Christian Wenz. Ich habe das Buch nun mal bestellt, mal schauen wie es ist.

 

[kkapsner]

Welche Schreibweise für Funktionen würdest du denn empfehlen?

Die erste:function foo(){}

bei einem Prototype

? Ein Prototype ist keine Funktion...?

für Methoden

"Methoden" sind in JS ja auch nichts anderes als Eigenschaften, die eine Funktion enthalten. Da man sie ja dem Objekt oder dem Prototyp zuweisen muss, hat man da irgendwo eine Zuweisung. Aber wie man die Funktion selbst erstellt, ist auch hier egal. Mit dem Funktionsausdruck ist das nur etwas kürzer (und man hat eine Variable weniger).

 

[Darry]

Danke. Momentan lese ich folgendes Tutorial:
JavaScript - OOP mit JavaScript - Konstruktorfunktionen - Methoden

Offensichtlich ist es so, dass ein Prototype eine Methode oder Eigenschaft ist, die bei der Konstruktorfunktion verwendet wird, um sie dann auf alle abgeleiteten Objekte zu vererben.

Was die Methoden angeht:
Die Schreibweise "function foo();" gefällt mir persönlich auch besser als die Schreibweise "var foo = function();"
Aber scheinbar gibt es Anwendungen, wo man um die Variablenschreibweise nicht herum kommt. Aber das hab ich noch nicht ganz so raus.

LG Darry

 

[kkapsner]

Naja - so wahnsinnig hat mich jetzt dieses Tutorial nicht vom Hocker... aber besser als nichts.

Ein Prototype ist prinzipiell einfach ein nur Objekt. Wenn man nun ein Objekt durch einen Konstruktor erstellt, um an diesem Objekt versucht eine Eigenschaft zu adressieren, die es nicht hat, wird in dem Objekt, das beim Konstruktor unter der Eigenschaft "prototype" gespeichert ist, nachgesehen, ob es diese Eigenschaft besitzt und dann diese zurückgegeben.

var proto = {inProto: true};
function Class(){}
Class.prototype = proto;

var b = new Class();
alert(b.inProto);
b.inProto = false;
alert(b.inProto);

Aber scheinbar gibt es Anwendungen, wo man um die Variablenschreibweise nicht herum kommt.

Doch, man kann (meistens) darum herum kommen. Aber das ist dann meist nicht besonders elegant und "müllt" den Variablennamespace oft ziemlich zu.
Die Fälle, bei denen man gar nicht darum herum kommt, sind extrem selten und auch eher akademischer Natur.

 

[Darry]

Das Tutorial ist zwar bei den Grundlagen recht verständlich, aber beim Thema OOP verzettelt er sich ein bisschen, hab ich den Eindruck.

Ich werde jedenfalls versuchen, Funktionen und Methoden konsequent in der Funktionsdeklaration zu schreiben.

Das mit den Klassen muss man aber nicht machen, man kann auch nur das Prototypensystem verwenden?
Oder wäre es im Hinblick auf die Zukunft besser, mit Klassen zu arbeiten?
In vielen Tutorials bzw Beispielen die sich etwas intensiver mit OOP unter JS befassen wird ja versucht, das Klassenmodell nachzubilden und nicht rein auf Prototypes zu setzen.

LG

 

[kkapsner]

Das Klassensystem aus ECMA6 ist jetzt auch nicht viel anders als das alte Prototypesystem. Es bietet vor allem syntaktischen Zucker. Aber es gibt auch Teile, die man mit dem alten System nicht abbilden kann (z.B. super oder die statischen Prototypes).

Ich würde mich aber trotzdem mit beiden beschäftigen. Das ältere System brauchst du, damit du auch wirklich verstehst, was da passiert, und das neue bietet gute Erweiterungen.

 

[Darry]

Danke.

Momentan beschäftige ich mich mit dem Prototypen Basierten System. Allerdings hat ActionScript damals auch von Prototypenbasiert auf Klassenbasiert gewechselt, und ich frage mich, ob das, was mit ES6 jetzt eingeführt wurde, der Anfang eines "Systemwechsels" ist.

Sprich, ob ich mich ehr auf die alte Variante beschränke, oder den "syntaktischen Zucker" voll mitnehme,

 

[kkapsner]

Das alte System wird aus Kompatibilitätsgründen ziemlich sicher nicht wegfallen. Und da du es für's Verständniss brauchst, würde ich mich zuerst damit beschäftigen. ABER das Neue würde ich danach auch mitnehmen.

 

[tsseh]

ach hier kommt das her

Das Klassensystem aus ECMA6 ist jetzt auch nicht viel anders als das alte Prototypesystem.

ich glaube indem du von altem und neuem klassensystem sprichst hast du ihn durcheinander gebracht. das "neue klassensystem" ist ja das "alte prototypesystem" nur mit erweiterter syntax, so daß man es jetzt schöner schreiben kann, bzw. einem auch viele sachen abgenommen, die man vorher hätte selbst machen müssen.

Aber es gibt auch Teile, die man mit dem alten System nicht abbilden kann (z.B. super oder die statischen Prototypes).

es gibt nichts, was man vorher nicht hätte auch machen können. statische methoden waren auch vorher schon möglich, man hat sie nur anders hingeschrieben als in anderen sprachen üblich.
das super-objekt hätte man sich auch vorher schon merken können, jetzt passiert das nativ

Ich würde mich aber trotzdem mit beiden beschäftigen. Das ältere System brauchst du, damit du auch wirklich verstehst, was da passiert, und das neue bietet gute Erweiterungen.

ich hab auch keine ahnung, wie man das besser ausdrückt, aber es sind ja keine 2 systeme, sondern 1 system, mit erweiterter syntax.

 

[Darry]

Laut JSperf ist die ES5 Schreibweise schneller als die ES6 Schreibweise.

ES5 wird besser unterstützt, viele Beispiele beziehen sich darauf. Dafür ist ES6 stellenweise "Schöner und Übersichtlicher" und es ist der aktuellste Standard.

Momentan bin ich daher echt am Überlegen, auf welche Schreibweise ich mich erstmal spezialisiere.

Nehme ich die ES5 Schreibweise mit Konstruktorfunktionen,, Literalen und object.create oder doch lieber class und extends aus ES6.

 

[tsseh]

Laut JSperf ist die ES5 Schreibweise schneller als die ES6 Schreibweise.

dürfte vermutlich egal sein

ES5 wird besser unterstützt,

ja

viele Beispiele beziehen sich darauf.

noch

Dafür ist ES6 stellenweise "Schöner und Übersichtlicher"

ja

Momentan bin ich daher echt am Überlegen, auf welche Schreibweise ich mich erstmal spezialisiere.

das hängt davon ab, was du machen möchtest. ausschlaggebend dürfte der punkt

ES5 wird besser unterstützt,

sein.
wenn dir das egal ist, nimm es6

 

[kkapsner]

es gibt nichts, was man vorher nicht hätte auch machen können.

Das dachte ich auch immer, aber dann hab' ich mich ein bisschen eingelesen und doch Unterschiede gefunden. Ich fand' das hier recht informativ: Classes in ECMAScript 6 (final semantics)

statische methoden waren auch vorher schon möglich

Ich meinte auch nicht statische Methoden, sondern wirklich die statischen prototypen. Bei extends wird der Prototyp der erzeugten "Klassenfunktion" auf die "Elternklasse" gesetzt:

function A(){}

class B extends A{}

A.test = function(){alert(1);}
B.test();

- sowas ist mit ECMA5 nicht machbar. Mir fällt jedenfalls nicht ein, wie man das realisieren könnte.

wie man das besser ausdrückt

Vielleicht sollte man besser von neuer und alter Syntax reden?

ES5 wird besser unterstützt

Das ist eine ziemliche Untertreibung. Noch nicht einmal im Chrome ist ES6 standardmäßig aktiviert.

 

[Darry]

Hi.

Also ich hab den aktuellen Chrome installiert. Class und Extends funktioniert da.
In Firefox klappt es nicht. Auf meinem Android Smartphone auch nicht.

Mein Beispielcode:

"use strict";

//Test einer Vererbungskette

//Konstruktor "Kfz"

class Kfz {
	constructor(ps) {
		this.ps=ps;
	}
	ausgabe() {
		console.log(this.ps);
	}
}

class car extends Kfz {
	constructor(ps,color) {
		super(ps);
		this.color=color;
	}
	farbe() {
		console.log(this.color);
	}
}


var vw = new car(60,"blau");
vw.farbe();
vw.ausgabe();

Ich habe mich aber entschlossen, auf ES5.1 zu gehen, auch wenn vielleicht einiges "unschöner" geschrieben werden muss.
ES6 wird mir doch noch zu wenig unterstützt.

Ich habe nun aber 2 Schreibweisen getestet, um Objekte zu erzeugen:

"use strict";

//Erzeugen eines Objektes mit new Object

var obj1 = new Object()
{
    obj1.firstName= 'John';
    obj1.lastName= 'Doe';
    obj1.sayName= function() {
        console.log(obj1.firstName + ' ' + obj1.lastName);
    }
}


var person1 = Object.create(obj1);
person1.sayName();

"use strict";

//Erzeugen eines Objektes mit Konstruktorfunktion

function Constr1()
{
    this.firstName= 'Jenny';
    this.lastName= 'Smith';
    this.sayName= function() {
        console.log(this.firstName + ' ' + this.lastName);
    }
}


var person2 = new Constr1();
person2.sayName();

Welche der beiden Schreibweisen ist denn besser?
Ich weiß, dass es auch noch weitere Schreibweisen gibt, z.B. die Literal-Schreibweise. Die Literalschreibweise gefällt mir aber nicht so, da dort die ganzen Zuweisungen anders geschrieben werden müssen. (Mit Doppelpunkt und Komma, statt mit Gleicheitszeichen und Semikolon) Und die "Klassische" Schreibweise gefällt mir besser, da sie "Universeller" ist.

Vererbung habe ich auch getestet, da bin ich einfach hin gegangen und habe das Elternobjekt beim Kindobjekt mit Object.create unter obj.prototype eingehangen, was auch soweit funktioniert hat.

"use strict";

//Test einer Vererbungskette

//Konstruktor "Kfz"
function Kfz(ps) {
	
	var privateVar = "foo";
	this.ps=ps;


	console.log("Konstruktor Kfz wurde aufgerufen "+Kfz.constructor.name);

Kfz.prototype.starten=function () {
		console.log("Motor gestartet");
}


};

//Konstruktor "Pkw"
function Pkw(marke,typ) {
	this.marke=marke;
	this.typ=typ;
	
	Kfz.call(this);

	console.log("Konstruktor Pkw wurde aufgerufen "+this.constructor.name);

	Pkw.prototype.fahren=function () {
		alert("Autofahren");
	};


};


//Vererbung des Prototype

Pkw.prototype= Object.create(Kfz.prototype);

var car1= new Pkw();
car1.starten();
car1.fahren();

LG

 

[tsseh]

sowas ist mit ECMA5 nicht machbar. Mir fällt jedenfalls nicht ein, wie man das realisieren könnte.

du kopierst einfach alle statischen methoden an deine neue klasse. da erwischst du idr. zwar nur die eigenen statischen methoden, kannst das aber auch auf native statische methoden ausweiten. das wird dann aber schon extrem unschön.
idr. bieten die frameworks das auch so an und man kann ein objekt übergeben dessen statische methoden kopiert werden.
ich find jetzt auf die schnelle nicht das was ich mir mal angesehen hatte, aber das hier, keine ahnung ob das was taugt
YUI Class - YUI Library

- - - Aktualisiert - - -

Welche der beiden Schreibweisen ist denn besser?

das kommt darauf an was du machen möchtest. willst du einfach ein objekt erzeugen nimmt man in der regel die literalschreibweise.
willst du methoden und eigenschaften kapseln geht das am schnellsten in einem konstruktor.
dein 1. beispiel ist übrigens suboptimal, da lokale variablen ohne es6 let keinen blockskope haben, du hier aber nur einen blockscope aufmachst, du hättest auch/noprmalerweise schreibt man

var obj1 = new Object();
obj1.firstName= 'John';
obj1.lastName= 'Doe';
obj1.sayName= function()
{
  console.log(obj1.firstName + ' ' + obj1.lastName);
};

 

[kkapsner]

Also ich hab den aktuellen Chrome installiert. Class und Extends funktioniert da.

Bei meinem musste ich das erst per Flag aktivieren.

Welche der beiden Schreibweisen ist denn besser?

Wenn du wirklich einfach nur ein Objekt erzeugen willst, würde ich immer über die Literalschreibweise gehen. Ist kürzer, besser wartbar und übersichtlicher.
Aber der Spaß an Construktoren sind ja v.A. die Prototypen, die deinen Code um einiges flexibler und schanker machen. So solltest du Methoden auch nicht im Konstruktor erzeugen, wenn es nicht sein muss. Sonst hast du ja für jede Instanz eine eigene Funktion, die Ressourcen verbraucht. Und wenn du dynamisch irgend etwas ändern willst, musst du jedes Objekt separat anfassen. Mit einem sauberen Prototyp musst du nur diesen ändern.

du kopierst einfach alle statischen methoden an deine neue klasse.

Mir ist schon klar, wie ich in ECMA5 statische Methoden "vererbe". Das war auch nicht mein Beispiel. Der Punkt war, dass auch nach dem Erstellen der Kindklasse statische Methoden bei Klasse A hinzugefügt werden können, die dann durch den Prototypen auch sofort bei B zur Verfügung stehen. Prototype-Vererbung eben... aber statisch.

- - - Aktualisiert - - -

noprmalerweise schreibt man

Ich würde normalerweise schreiben:

obj1.sayName= function(){
  console.log(this.firstName + ' ' + this.lastName);
};

- dann ist die Funktion flexibler...

 

[tsseh]

Aber der Spaß an Construktoren sind ja v.A. die Prototypen, die deinen Code um einiges flexibler und schanker machen.

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

So solltest du Methoden auch nicht im Konstruktor erzeugen, wenn es nicht sein muss.

wenn man überhaupt einen konstruktor verwendet, dann doch genau aus dem grund dort private methoden zu erzeugen. dann müssen (fast) alle anderen funktionen (meist) auch dort implementiert werden.

Sonst hast du ja für jede Instanz eine eigene Funktion, die Ressourcen verbraucht.

nicht der rede wert, sonst könnte man im gegenzug den overhead durch den zugriff über den prototypen ins spiel bringen. beides ist vernachlässigbar. (auch sollte die property in beiden fällen auf ein und die selbe funktion zeigen, wenn das vernünftig optimiert ist)

Und wenn du dynamisch irgend etwas ändern willst, musst du jedes Objekt separat anfassen. Mit einem sauberen Prototyp musst du nur diesen ändern.

dafür gibt es eigentlich keinen vernünftigen grund, im gegenteil ich finde das sogar gefählich. wenn objekte im nachgang erweitert werden kommt dafür eigentlich nur eine bibliothek oder ein nativ browserobjekt infrage, welches angepasst werden soll, jedenfalls kein eigenes. dann muss das aber zwingend als erstes passieren, weil du sonst nicht sicher sein kannst, ob die erweiterung schon passiert ist oder nicht.

Der Punkt war, dass auch nach dem Erstellen der Kindklasse statische Methoden bei Klasse A hinzugefügt werden können, die dann durch den Prototypen auch sofort bei B zur Verfügung stehen.

nenn mir mal einen usecase dafür, und dann noch einen grund das nicht zu einem definierten zeitpunkt zu machen

 

[Darry]

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

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

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

Anhand der Browser compatibility List lässt sich sehen, dass let sogar noch vom IE11 unterstützt wird. Und beim aktuellen Firefox 44 wird es auch unterstützt ohne Flag.
D.H. man könnte es ja schon verwenden. Nur bei Android und ios leider noch nicht.
Was ich auf jeden Fall vermeiden will, sind Transpillers. Ich will, dass es auf den derzeit aktuellen Browsern läuft ohne eine weitere Baustelle aufzumachen.


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

"use strict";

//Erzeugen eines Objektes mit dem Literal
var mensch = {};

//Eine Eigenschaft hinzufügen, vorbelegt mit Defaultwert
mensch.vname="unbekannt"

//eine Methode
function sagWas(text) {
	this.text=text;
	alert("Hallo, ich bin "+this.vname+" und sage "+ text);
};

//Methode in das Objekt einhängen
mensch.sagWas=sagWas;


//Kinder erzeugen
var person01=Object.create(mensch);
person01.vname="Monika"
person01.sagWas("bla");

var person02=Object.create(mensch);
person02.vname="Franz"
person02.sagWas("Hallo");

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?

LG

- - - Aktualisiert - - -

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



Dann wäre es ja einfacher (und intuitiver) ein Objekt selber zusammen zu setzen, anstatt mit Konstruktorfunktionen und setzen von Prototypen zu arbeiten.

LG