[FRAGE] Konstruktooooor mit Prototype

[this]

Bitte helft mir bei diesem kleinen Prototypen Verständnisproblem .
Ich habe zu folgendem Bsp. eine Frage

Warum wird bei dieser KonstruktorFunktion Screen hier

 function Screen(){};

nicht die benötigte Methode draw gleich in dem Screen Object eingefügt sondern in das prototype Object eine Zeile weiter?

 Screen.prototype.draw = function(data){return this.data;};

Hab das bisher noch nicht verstanden warum das im Prototypen eingehangen wird?

 

[tsseh]

wenn du es beim prototypen einhängst, und ein weiteres objekt von Screen erben lässt, hat dieses dann gleich die methode draw.
wenn du das im konstroktor einhängst, musst du die Screen-konstroktor-funktion in deiner abgeleiteten konstroktorfunktion mit deinem this als context aufrufen um die methode draw zu erben.
der entscheidende nachteil bei der prototype variante ist der, dass du dann auf keine privaten daten zugreifen kannst, womit das aus meiner sicht zu 99% nicht praktikabel ist.
manch einer würde vielleicht noch erwähnen, dass du in der konstroktorvariante jedesmal mal beim anlegen einer instanz die methode erst zum objekt hinzufügen musst und sie bei der prototype variante nur ein einziges mal am prototyp hinzugefügt werden muss und das zeit kostet. das kannst du aber getrost vernachlässigen.

 

[this]

Danke für die Antwort, was soll dann eigentlich der praktische Vorteil von Prototyping in diesem Fall hier sein?
Man sieht es in einigen Tutorials auch.
OOP in JavaScript || Vererbung
Ohh darf man hier einen externen Link einbringen?
VG

 

[tsseh]

Danke für die Antwort, was soll dann eigentlich der praktische Vorteil von Prototyping in diesem Fall hier sein?

im vergleich zum hinzufügen einer methode an der/jeder instanz? du kannst beides machen. ob oder auch nicht und in welcher situation was ein vorteil ist kannst du selbst entscheiden. über den prototypen:
* du musst es nur 1 mal tun
* dadurch dass du es einmalig nur am prototypen einfügst spaarst du laufzeit und speicherplatz
* du kannst den prototypen selbst zur laufzeit ändern
* du hast keinen zugriff auf pseudo-private daten

 

[kkapsner]

Zusätzlich kann man über die prototype-chain Vererbung recht schön abbilden - besonders in Zusammenarbeit mit dem dritten Punkt von tsseh: du kannst den prototypen der Elternklasse zur Laufzeit anpassen und die Änderungen sind sofort bei den Instanzen der Kinklassen sichtbar.

PS: man kann sich schon einen Zugriff auf pseudo-private Daten bauen:

var Test = (function(){
	var private = new WeakMap();
	function Test(value){
		private.set(this, value);
	}
	Test.prototype.getValue = function getValue(){
		return private.get(this);
	}

	return Test;
}());

var a = new Test(1);
var b = new Test(2);

console.log(a, a.getValue(), b, b.getValue());

- funktioniert natürlich nur in Browsern, die WeakMap unterstützen.

 

[tsseh]

besonders in Zusammenarbeit mit dem dritten Punkt von tsseh:

der ja nichts mit vererbung zu tun hat

du kannst den prototypen der Elternklasse zur Laufzeit anpassen und die Änderungen sind sofort bei den Instanzen der Kinklassen sichtbar.

was man meiner meinung nach tunlichst vermeiden sollte

 

[kkapsner]

was man meiner meinung nach tunlichst vermeiden sollte

Warum?

 

[tsseh]

weil du damit eine weitere/unnötige abhängigkeit einbaust für die es keinen grund gibt.
als entwickler der bibliothek kannst du die funktionalität sowieso von vornherein einbauen und als anwender ist es gefährlich an der bestehenden bibliothek rumzufuschen schon aus kompatibilitätsproblemen.

 

[kkapsner]

Bei diesen beiden Fällen hast du recht, aber ich dachte jetzt eher an eine Frameworkerweiterung (Modularität), die nicht jeder benötigt und sehr groß ist.
Auch gibt es den Fall von nicht Bibliotheksklassen, die verschiedene Teile haben, die von verschiedenen Leuten entwickelt/verwaltet/gewartet werden. Da empfielt es sich dann verschiedene Dateien zu haben, die auch einen separaten Scope haben.