[Erledigt] Javascript Klasse

[oxyd21]

Hi,

irgendwie bekomm ich's nicht hin. Ich hab folgende Klasse in einer Scriptlib:

Code

function ProfilesClass() {
	
	var m_profiles = null;
	var m_staff = null;
}	
	ProfilesClass.prototype.setCurrentUserProfile = function() {
		return "xyz"
	}

	ProfilesClass.prototype.setCurrentUserStaffDB = function() {
                var profil = ProfilesClass.getProfiles; //hier bleibt hakt's wahrscheinlich
		return profil
	}
	ProfilesClass.prototype.getStaffDb = function() {
		if (ProfilesClass.m_staff == null) {
			ProfilesClass.m_staff = ProfilesClass.setCurrentUserStaffDB;
		}
		return ProfilesClass.m_staff
	}
	ProfilesClass.prototype.getProfiles = function() {
		if (ProfilesClass.m_profiles == null) {
			ProfilesClass.m_profiles = ProfilesClass.setCurrentUserProfile;
		}
		return ProfilesClass.m_profiles
	}

Das Ergebnis will ich in einer XPage verwenden, was aber grundsätzlich leer bleibt.

Code

var objProfiles = new ProfilesClass();
return objProfiles.getStaffDb()

Ich hab's jetzt gefühlte 20x umgebaut, finde aber meinen Fehler nicht so recht. Die Berechnungen hab ich entfernt.

VG, Michael

[oxyd21]

Oh man 

Mit nem this statt dem Klassennamen klappt's.

[flaite]

Dabei kennt JavaScript überhaupt keine Klassen sondern nur Objekte und Prototypes. 
http://aktuell.de.selfhtml.org/artikel/javascript/oomodell/
In deinem Beispiel macht der Einsatz von prototypes aus meiner Sicht keinen Sinn.
Benutzt Lotus in ihrem XPages-JavaScript den Begriff class  


   
   

[oxyd21]

Danke für die leicht herablassende Belehrung. 

Ich hatte in meinem ersten Entwurf auch keine Prototypen drin. Da ich jedoch den nachfolgenden Fehler bekam, und es verschiedene Wege zur Simulation von Klassen, habe ich mich für den funktionierenden Weg entschieden. Du darfst natürlich gerne meine Denkfehler im Code verbessern.

[TypeError] Error calling method 'getProfiles()' on an object of type 'Object [JavaScript Object]'

Hübsch-programmieren tue ich dann in meiner JS-Objektbeschreibung.   

[flaite]

Zorry. Das war nicht herablassend gemeint.
Aber JavaScript ist nun einmal eine objekt-orientierte Sprache, in der es Klassen nicht gibt.
Ich bin selbst eher JQuery user als großer JavaScript-Kenner.

Du könntest es einmal so versuchen.

Code

function getProfilesObject() {
	var profilesObject = new Object();
	profilesObject.m_profiles = null;
	profilesObject.staff = null;
	
	profilesObject.setCurrentUserProfile = function() {
		return "xyz"
	}
        // etc...
}

// use-> 
var myProfilesObject = getProfilesObject();
getProfilesObject.setCurrentUserProfile();

[Gandhi]

Nur mal was Grundsätzliches/Philosophisches: Wozu sollte ich Klassen simulieren, wenn ich keine brauche?

Es gibt in der weiten Welt (der Programmierung) nichts, wozu ich eine Klasse benötige. Turing-vollständig sind auch prozedurale und funktionale Sprachen.

[oxyd21]

Ganz klar 42 ... oder die Antwort auf deine Frage ist die gleiche, wie z.B. auf die Frage 'Wozu existiert die Firma Porsche, wenn der Mensch Beine hat?'

[Gandhi]

Im Fall der Firma Porsche ist das eindeutig zu beantworten:
Weil ich mit einem Produkt dieser Firma (in Verbindung mit meinen Beinen) schneller von A nach B komme.

Im Fall der Klassen sieht das anders aus: Klassenorientierte Programmierung ist nicht nachweislich schneller/effizienter als eine anderem Paradigma folgende (lasse mich hierzu gerne korrigieren unter Angabe einer Quelle/Studie).

In JavaScript ist es auf keinen Fall in irgendeiner Weise schneller klassenemulierend zu arbeiten.
Objekt-objektorientiertes, funktionales und Mixin benutzendes Arbeiten ist auf jeden Fall schneller und vor allem auch sauberer, da diese Features von JS unterstützt werden und auch per se keinesfalls weniger mächtig wären.

[oxyd21]

Die Beantwortung deiner Frage ist zu kurz gedacht. Warum musst du schneller von A nach B kommen. Macht es dich glücklicher? (abgesehen vom kurzfristigen Hochgefühl das einem über kurz oder lang nicht mehr befriedigt) Wenn du nicht die Möglichkeit hättest schneller die Strecke zu überwinden, hättest du dann auch das Bedürfnis dieses zu tun? Wobei du vielleicht die eingesparte Zeit verwenden könntest um dein nächstes Produkt der Firma zu realisieren.

Warum hat Picasso den Menschen die Nase an die Seite gemalt? Macht es Sie deshalb hübscher? Wäre es nicht viel schöner, er hätte es augenschmeichelnd wie da Vincis Mona Lisa gemalt?

Du hast bestimmt recht, aber in meinem Fall ging es nie um Performanz, sondern nur darum etwas zu lernen. Ich habe m.E. mein Ziel erreicht (auch wenn's keine Mona Lisa geworden ist ).

[flaite]

@Gandhi: Das seh ich wiederum als ein ganz anderes Thema.
Warum stellt man Fragen in ein Forum und versucht es nicht selbst herauszufinden   Schließlich ist der uns allen eigene Verstand für diese Aufgabenstellungen turing-complete.

Objekt-Orientierung kann durchaus die Arbeit erleichtern.
JavaScript ist aber keine klassen-basierte OO-Sprache sondern eine prototype basierte OO-Sprache.
Und das Verständnis solcher konzeptionellen Feinheiten sind nicht unbedingt akademisch, sondern können die Arbeit erleichtern.

So basiert die erfolgreiche und nicht unbedingt so irrsinnig zeitaufwendige Lösung des Problems in diesen Thread (http://atnotes.de/index.php/topic,52899.0.html) auf Polymorphismus und den Pattern Inversion-of-Control/Dependancy Injection, Command und Factory Method. Neben dem es DANN AUCH TUN.

Das ist jetzt keine persönliche Kritik. Man MUSS SICH NICHT um das Verständnis der Konstruktionspläne einer Programmiersprache bemühen, um sie benutzen zu können. Alles was ich sage ist: Es kann die Arbeit erleichtern.

Wenn der Fragesteller da empirisch vorgeht und es einfach ausprobiert, ist das völlig i.O.. Man kann aber auch Crockford, Douglas, JavaScript: The Good Parts, O'Reilly 2008, ca. 150 Seiten lesen und nach ein bischen Kopfe-Schmerzen verstehen, warum es funktioniert wie es funktioniert.

Kurzes Beispiel was mit Prototype basiertem OO möglich ist. Erweiterung des String Prototypes von JavaScript.

Code

<html>
<head>
<script>
String.prototype.contains = function(it) { return this.indexOf(it) != -1; };
function containsText(needle, stack) {
    if (stack.contains(needle)) {
	 return stack + " contains " + needle;
	} else {
	 return stack + " does not contain " + needle;	
	}
}
</script>
</head>
<body>

<form>
<input type="button" value="needle=weih, stack=weihnachten" onClick="alert(containsText('weih', 'weihnachten'))"/>
<input type="button" value="needle=ostern, stack=weihnachten" onClick="alert(containsText('ostern', 'weihnachten'))"/>
</body>
</html>

Kommentiert dann mal diese Zeile aus:  
String.prototype.contains = function(it) { return this.indexOf(it) != -1; };
... und versucht es nochmal.

Gruß Axel

[koehlerbv]

Michael, auch wenn wir jetzt völlig off-topic sind (und jeder bisher irgendwie Recht hatte  ):
Porsche ist Murks in dem Sinne: Wenn man schon extravagant sein will (sooo besonders schnell ja nicht unbedingt!) und zuviel Schotter hat, dann Mi-24. Die ist schneller, bietet viel mehr Platz, hat den tolleren Klang und ihr ist nichts im Weg. Zudem noch bis zu acht Plattformen für "Wir machen den Weg frei!" - falls es mal hart auf hart kommt. Und für andere Hindernisse wie Berge und Hochspannungsmasten gibt es jeweils natürlich auch 'ne App   Die Reichweite ist auch besser. Viel besser. Der Sprit ist natürlich eher besonders und fliesst reichlich, ist aber im Literpreis billiger. Alles hat seine Vor- und Nachteile.

Was Picasso und da Vinci angeht: Hätte Picasso die Nasen an die richtige Stelle gepappt, wären daraus noch immer keine "schönen Menschen" geworden. "Guernica" ist für mich trotzdem ein beeindruckendes Bild.
Die "Mona Lisa" ... Okay, wenn zwangsweise auf einer Insel ausgesetzt und eine Frau dabei, dann eher diese als Picasso-Figuren - da muss man wenigstens nicht gleich vor Entsetzen ins Meer springen  

Back to topic: Es gibt oft mehrere Wege, Code stabil, wartbar, wiederverwendbar zu machen. Hauptsache, man treibt nicht jeden Tag eine neue Sau durchs Dorf ... und bleibt niemals stehen, wo man ist. Eine "neue Sau" kann natürlich auch sehr hilfreich sein.

Bernhard

[flaite]

Ok. Ich hab Marco nicht aufmerksam gelesen. Bin nämlich mit Dir glaub ich völligst einer Meinung.
In die gleiche Richtung geht auch meine zunehmende Ablehnung von dojo, mit dem ich gearbeitet habe, insbesondere im Vergleich zu jQuery, das ich für wesentlich effektiver halte.
In dojo wird krampfhaft versucht, ein Klassen-Schema in eine Sprache zu bringen, die das einfach überhaupt nicht benötigt.

[Gandhi]

Und wo wir hier schon bei Buchempfehlungen sind: Neben Crockford - dessen Buch wirklich das wohl beste JS Buch auf dem Markt ist, kann ich Stoyan Stefanov sehr empfehlen, insbesondere das Buch über Design Patterns in JavaScript.

Back to topic:
Was ich damit sagen will: Aus meiner Sicht ist die Klassenorientierte Objektorientierung nicht in irgendeiner Weise effizienter als andere Paradigmen.

Die beiden vorherrschenden Paradigmen von JavaScript sind die Funktionale Programmierung und die Prototypische Objektorientierung (eigentlich einfach nur Objektorientierung - wenn man im anderen Fall korrekterweise von Klassenorientierung sprechen würde).

Wirklich gut zu nutzen ist JavaScript nur, wenn man sich auf JavaScript einlässt und es nicht versucht umzuinterpretieren.
Genauso mit Java, C++, ...
Sprachen haben Stärken, Sprachen haben Schwächen - Klassenorientierte Objektorientierung und Interfaces sind keine Stärken von JavaScript.
Der Rest schon. Bin noch am Erkunden, was man alleine mit funktionaler Programmierung anfangen kann - das ist ein weites faszinierendes Feld.

JavaScript wird nach meiner Meinung noch eine noch größere Rolle im IT Zirkus bekommen. Nicht nur im Frontend und nicht nur in Domino SSJS, sondern auch im Zusammenhang mit Cloud Computing, V8/Node.js

JQuery oder Dojo? Ich bevorzuge Dojo. Weniger weil ich glaube, dass es besser ist, sondern weil es in sich vollständiger ist. Es gibt zwar gleiche Funktionalitäten auch unter jQuery über Erweiterungen - da ist dann aber nicht mehr alles aus einem Guss.  Wenn ich auf Dojo basierend im Dojo Stil Erweiterungen basteln würde, hätte ich vielleicht die gleichen Probleme - ich nutze es aber weitgehend unverändert, also ohne irgendwelche Erweiterungen aus Dojo zu basteln.
Vielleicht wäre jQuery auch so besser - aber Dojo ist einfach gut genug für mich und meine Zwecke.

[flaite]

Naja. Ich hab meinen Senf dazugegeben, weil ich den Eindruck hatte, dass Michael einem oft eingesetzten, aber problematischen Vorgehensmodell folgte.

1.) Sich sagen: Ich weiss, "was Objekt-Orientierung ist" Objekt-Orientierung ist mit Klassen. 
2.) Mit dem "Vor"-Urteil von 1.) code schreiben.
3.) Solange auf den Code einprügeln, bis er das tut, was ich denke OO in der Sprache darstellt.
4.) Einer Reflektion, ob 3) den code verständlicher, erweiterbarer und anpassbarer macht, ausweichen. 

OO ist aber wie praktisch jeder abstrakter Begriff ein oft sehr dehnbares Konstrukt. Eine abstrakte Hülle. Eine Art Götze, der für etwas steht, das allzuvoft mehr durch Hineinfabulieren des Betrachters bestimmt wird als das Ding für sich. 
Wichtiger und herausfordernder ist aber für mich eigentlich die Frage, wie OO in der konkreten Implementierung der Sprache verstanden und wie ich das nützen kann. Und ich hatte den Eindruck, das Michael vor diesen Fragen ausweicht. Und ich hab einfach vorgeschlagen, das noch einmal zu überdenken. Eigentlich eine Forderung nach mehr Demut in der Annäherung gegenüber dem Inhalt des Begriffes. Deshalb widersprach ich auch dem Arroganz-Vorwurf gegen mich.   

Gruß Axel

[Gandhi]

Sehe ich ähnlich