JS OOP: singleton() oder statische Funktionen oder namespaces irgendwie realisierbar?

[Sholvar]

Ich sitz gerade daran, den Code eines ehemaligen Mitarbeiters zu überarbeiten und frage mich alle 2 Funktionsaufrufe, wo die Funktion eigentlich definiert wird. Deshalb würde ich gerne eine Möglichkeit einführen, vor jeder Funktion zu sagen, wo die her kommt. Am liebsten wäre mir singleton. Gibt es sowas in JS überhaupt? Das man "Klassen" im Prinzip nur als Funktionen definiert hab ich schon herausgefunden. Weiter bin ich in diese kreative OOP von Javascript noch nicht vorgedrungen.

 

[voelkerballtier]

was meinst du mit "vor jeder Funktion" ?
€: also um das "vor" gehts mir - ich verstehe halt nich so ganz was du willst

 

[BiBaButzemann]

Statische Variablen gibts nicht (musst mit "root" Variablen arbeiten, wenn du mal was klassen- bzw funktionsübergreifendes brauchst)

"Richtige" Singletons damit auch nicht. Wobei das noch so halbwegs umschusterbar durch diese Root-Variablen ist - aber naja schön ists nicht...

Ich irre mich in beiden Punkten aber nur zu gern. Hab auch gerade 2 Projekte mit viel JS und Spass macht das nicht.

Hab mir jetzt ne kleine Buffer Hilfsklasse gebaut, mit der ich z.B. nach Events wieder in die Trigger-Klasse zurückkomme - halt ne Art Notlösung um nicht völlig dreckig schreiben zu müssen.

 

[Sas~iN~LoVe]

Hilft das nicht?

http://www.javascriptkata.com/2007/04/04/how-to-make-a-singleton/
http://dhtmlkitchen.com/learn/js/singleton/
http://www.kaijaeger.com/articles/the-singleton-design-pattern-in-javascript.html
http://dhtmldev.com/content/view/27/26/

Ich hab Javascript noch nicht für mehr als ein Popup auf ner Webseite vor vielen, vielen Jahren genutzt, daher habe ich mir gar nicht alles durchgelesen. Aber Treffer gibt es noch und nöcher...

Edit: Ok, gängiger Workaround sind wohl anonyme Methoden.

 

[Sholvar]

Original geschrieben von BiBaButzemann
Statische Variablen gibts nicht (musst mit "root" Variablen arbeiten, wenn du mal was klassen- bzw funktionsübergreifendes brauchst)

"Richtige" Singletons damit auch nicht. Wobei das noch so halbwegs umschusterbar durch diese Root-Variablen ist - aber naja schön ists nicht...

Ich irre mich in beiden Punkten aber nur zu gern. Hab auch gerade 2 Projekte mit viel JS und Spass macht das nicht.

Hab mir jetzt ne kleine Buffer Hilfsklasse gebaut, mit der ich z.B. nach Events wieder in die Trigger-Klasse zurückkomme - halt ne Art Notlösung um nicht völlig dreckig schreiben zu müssen.

also so eine Art übergabe der Vaterklasse als Parameter? So würde ich das jetzt zumindest als Denkanstoß verstehen. Und es klingt erstmal wie das brauchbarste, was ich dazu bisher gelesen habe

@voelkerballtier:

Ich meine folgendes:
Math.random(); als Beispiel aus Java. Wenn ich diese Funktion irgendwo im Quellcode sehe und später nachgucken möchte, wo die liegt und was konkret in der Funktion passiert, dann weiss ich kann in die Klasse Math gucken.
Bei Javascript begegnet mir irgendwo im code, wo vielleicht 20 oder 30 JS Dateien improtiert wurden random(); Da weiss keiner, wo die jetzt zu finden ist, außer vielleicht die Person, welche die 20 Dateien geschrieben hat.
Deshalb möchte ich einen Weg finden, bei dem auch in JavaScript vor jeder noch so kleinen Funktion ein Klassenname steht (den ich dann durch die Coding Styles gleich bindend mit dem Dateinamen verknüpfe). Ein Objekt wäre für mich auch okay, wenn man sowas wie das Singleton-Pattern sicherstellen könnte.


*edit*

so bin durch sas' Links durch. Man, hättest doch einfach den vierten Link zuerst stellen können ^^ die qualität steigt von oben nach unten mit jedem Link erheblich

Ich denke das letzte ist perfekt. Weil es genau das ermöglicht was ich suche. So ist jeder gezwungen vor Aufruf einer Funktion noch einen Variablennamen zu schreiben. Superb!
Wenn das die nächten Tage von den Codern als Schrott zurück kommt, meld ich mich nochmal

 

[voelkerballtier]

ach so alles klar. ich dachte du willst irgendwie bei bestehendem code (automatisiert) rausfinden, wo die funktion definiert wurde...

Also wenn es wirklich nur darum geht, nenn deine Funktionen doch einfach Math_random() - zwar nicht so elegant wie statische Klassen, aber irgendwelche wilden konstrukte, am besten noch per document.write wieder js-code ausgeben, werden auch nicht wirklich besser...

€ ok sowas ähnliches wie im 4. link steht hab ich hier auch grad geschrieben - hab vorher auch nicht alle durchgeklickt

 

[TriloByte]

Singletons sind mieser Programmierstil.
http://www.riedquat.de/prog/singletonsAreEvil

Das muß doch irgendwie besser lösbar sein. Arbeitet ihr eigentlich mit nem anständigen JS-Framework wie prototype oder jquery?

 

[BiBaButzemann]

Beides.
Prototype für Ajax, da ich irgendwie bei jQuery die Scriptausführung nach mit Ajax reingeladenen Elementen nicht hinbekomme (die Option hatte irgendwie nen Namen, weiss es aber gerade nicht - hab zumindest jQuery in noConflict dann gestartet und Ajax mit Prototype gemacht).

Sonst jQuery, wobei sich jetzt beide nicht viel nehmen und irgendwie nur Geschmackssache sind. Bei jQuery mag ich das $('document').ready(), das hat Prototype afaik nicht drin.
Aber Beide sind ja eher für schnelles DOM-Tree verändern gut und nicht für so "globale" Workarounds von irgendwelchen rein mathematischen Sachen ohne irgendwelchen visuellen Output gedacht.

Und wir reden hier von JavaScript und nicht Java - da ist ein halbwegs anständig sauberer Code schon nen Luxus.

edit - evalScript wars

 

[Sholvar]

Original geschrieben von TriloByte
Singletons sind mieser Programmierstil.
http://www.riedquat.de/prog/singletonsAreEvil

Das muß doch irgendwie besser lösbar sein. Arbeitet ihr eigentlich mit nem anständigen JS-Framework wie prototype oder jquery?

Wie du weiter oben erkennen kannst, ist das Problem schon soweit gelöst, dass es eher dem Aufruf statischer Funktionen als dem von Singleton entspricht. Und solang du keine Attribute im Singletonobjekt hast, wird auch kein Zustand gehalten, der auf andere Unit-Tests Auswirkungen haben könnte.
Zuerst wollte ich mich für die Info bedanken, aber in dem Link wird das Thema zu flach behandelt. Was in einer Situation schlecht ist, kann in einer anderen ganz gut sein. Coding for Testability ist ja leider nicht das einzige Programmierziel. Zum Beispiel sind einige Sachen nicht sehr performant, wen sie testable programmiert sind. Oder sie genügen nicht den Sicherheitsstandards. Usw.
Ich will damit sagen, dass wir kein Pattern ausschliessen sollten, nur weil es in einer Situation ungünstig ist.

Und aus performancegründen nutzen wir keine Frameworks und programmieren das Minimumframework selbst, sofern wir überhaupt frameworksachen brauchen.

 

[Sas~iN~LoVe]

Ich denke auch, dass der Text zu sehr verallgemeinert. In den beschriebenen Testszenarien kann man sie ggf. durch Mocks ersetzen.

Nich nur in Java dank des ClassLoaders kann man Singletons mehrmals instanzieren, auch in .NET geht das, wenn man will, mittels Reflection. Aber ich finde das nicht schlimm. Wichtig ist, dass es nicht aus Versehen passieren kann. Wenn man das macht, dann tut man es _bewusst_.

Der Text dagegen argumentiert nach dem Schema "Gesetze sind nicht sinnvoll und können gleich ganz abgeschafft werden, da man sich ja darüber hinwegsetzen kann". Würde ich auch nicht unterschreiben.