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

[MB]

moin,

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

Sry, ich war mit der Stellung der Frage hin und her gerissen: Neuer Thread oder unter deiner Antwort posten 🤔. Ich hab mich für's zweite enschieden.

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.

Sry 😅, ich bin im Abbreviation-Wahn 😔. Ich dachte OO liest sich leichter als 'Object oriented' und OB für 'Object based'. Jedenfalls gehts mir so und man macht weniger Fehler bei zwei Buchstaben. Sry dafür wenn der Schuss nach hinten los ging 😕.

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.

Ein Tutor von Udemy sprach von Syntactical Sugar wo sich Objektorientierte-Programmierer wohl in der Klassen-Syntax heimischer fühlen würden. Das könne man mit objektbasierender weise eleganter, besser und performanter hinkriegen. Das habe ich so verstanden und interpretiert. Ich schlussfolgerte, dass ich wohl beim lernen von Prototypen-Vererbung bleibe.

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.

ich hab's befürchtet, dass das n Performance-Problemchen werden würde, wenn man tausende Objekte erzeugt. Die new-Funktion schneidet besser ab?

Was man vermeiden sollte, ist, in der Konstruktorfunktion Methoden an this zuzuweisen.

Das ist mir neu. Ich dachte, jede Prototyp-Funktion eines Konstruktors schleppen auch immer this-objekt mit Referenz auf die Instanz mit sich rum oder nicht? In dem Fall wäre es doch Jacke wie Hose?

Ich hoffe wir reden nicht aneinander vorbei 😕. Daher will ich das am Beispiel veranschaulichen…

Bsp. 1.

const Foo = function( bar ) {
  this.bar = bar;
};
Foo.prototype.getBar = function(){
  return this.bar;
}

oder

Bsp. 2.

const Foo = function( bar ) {};
Foo.prototype.getBar = function(){}

Beide Beispiele enthalten doch this-Objekte. So mein Verständnis eines noch-nicht-javascript-entwicklers 🤔.

lgmb

PS.: Ich bin Agnostiker! Papst hin oder her, wenn auch nur JavaScriptPapst 🤪.