Warum bei Prototype-Inheritance die Konstruktor-Funktion von Parentclass zu Childclass wechseln???

[Rolf B]

Hallo MB,

ich komme bei deinen Rückfragen nicht so ganz mit. Kann dran liegen, dass das Thema 5 Tage alt ist 😉

Deine Frage war doch:

Gibt es einen Weg ein Objekt zu erzeugen mit Übergabewerten ohne den new-Operator???

Und ich hab nicht verstanden, warum das ein Problem sein sollte. Das einzige, was ich mir vorstellen konnte, war, dass Du einen Fall hast, wo Du nur den Prototyp kennst (oder eine existierende Objektinstanz), aber nicht die Konstruktorfunktion direkt.

Dein Object.create(Foo) hilft da beim Verständnis auch nicht weiter, denn der Parameter für Object.create ist das Prototypobjekt, das für das neue Objekt verwendet werden soll. Bei Dir ist Foo aber eine Funktion.

Jetzt stellst Du eine andere Behauptung auf:

Mir ist bekannt das in JS der new Operator ungern gesehen wird, da es ja nicht OO sondern OB ist.

Aha. Soso. Mir ist das nicht bekannt. Mir ist auch nicht bekannt, was "OB" ist. Aber ich bin auch kein JavaScriptpapst, nur ein einfacher Programmierer. Welche Quelle hast Du da? Wenn ich nach OO OB googele oder bingele, finde ich nur irgend so einen ollen Jedimeister. Nicht hilfreich.

Der new Operator ist gerade dafür gemacht, um die klassenorientierte OO in JavaScript nachzubilden. Er ist ideal für den Fall, dass man Objekte mit Prototyp anlegen und mit Hilfe einer Funktion initialisieren möchte. Einen Performance-Nachteil hat er nicht.

Deine "Erzeuger" Funktion behandelt einen Sonderfall, nämlich, dass man extrem generisch über eine Key-Value Liste Objekte initialisieren können möchte. Auf diese Weise fängt man sich schon einen Performance-Nachteil ein. Aber selbst der fällt nicht auf, wenn man lediglich einige Objekte auf diese Weise anlegt. Nur wenn man Code hat, der in kurzer Zeit hunderte oder tausende von Objekten erzeugen muss, kann das weh tun.

Was man vermeiden sollte, ist, in der Konstruktorfunktion Methoden an this zuzuweisen. Denn das ist Käse. Für jede dieser Zuweisungen muss JS ein neues Funktionsobjekt anlegen und der Aufrufkontext der Konstruktorfunktion klebt als Closure noch dran fest. Methoden sollte man nur am Prototypen haben und in die Objekte hineinvererben. Gut - ich hatte schon Fälle, wo ich im Konstruktor Methoden zugewiesen habe, einfach um den Kontext der Konstruktorfunktion als privaten Datenspeicher zu haben. Aber dafür gibt's mittlerweile auch die private Features der class Syntax (etwas, was sich anders gar nicht realisieren lässt)

Rolf