Statische Initialisierung: Reihenfolge erzwingen

[bokel]

Mein kleines Loggingsystem behandelt ein interessantes Problem. Es besteht aus einer statischen Loggerklasse und einige Listenern, die sich automatisch per statischer Initialisierung miteinander verknüpfen sollen, genauer, die Listener sollen sich beim Logger als Listener anmelden. Dabei gibt es aber das Problem, dass die Listener eventuell vor dem Logger initialisiert werden oder auch umgekehrt, jenachdem wie der Compiler die Klassen anordnet.
Ich habe es so gelöst, dass sowohl der Logger als auch die Listener von der gleichen BaseKlasse erben, die dann auf jeden Fall zuerst existieren muss. Das gegenseitige Anmelden geht dann über die Baseklasse. Das funktioniert zwar irgendwie, aber so richtig clean ist das nicht. Was fallen euch noch für andere Lösungen ein?

mfg. r

[bokel]

Noch dreckiger, alle erben vom Logger. Dann ist zusaetzlich gesichert, dass der Logger zuerst da ist.

[bokel]

Manchmal kommt man nicht auf die einfachsten Sachen

Die Listener erben von einer gemeinsamen Basisklasse. In der Basisklasse wird eine Referenz auf den Logger-Singleton gespeichert. Dann klappts auch mit dem Nachbarn.

mfg. r

[bokel]

grr, nee genau das klappt nämlich nicht - durch die statische Initialisierung der Listener ist nicht sichergestellt, dass die LoggerKlasse schon initialisiert ist.

[artjom]

Dabei gibt es aber das Problem, dass die Listener eventuell vor dem Logger initialisiert werden oder auch umgekehrt, jenachdem wie der Compiler die Klassen anordnet.

meinste mit dem initialisieren irgendeine init methode? wenn ja, dann hat der compiler ja nix mit der initialisierungsreinhenfolge zutun. ich denke du meinst die reihenfolge der initialisierung von klassenvars während der kompilierung.
wenn du doch sicherstellen willst, dass dein logger vor den listenern initialisiert werden soll, kannst du instant nen adapter für deine listener schreiben, in dem das interface und ne statische variable des Logger-typs drinne is:

PHP-Code:

class bokelsAdapter implements myInterface{
 private static var m_objTemp:Logger;
} 


so hat das kompilerchen den logger vor dem konstruktor des adapters und somit vor dem listener.

.. oder ich check das problem net

gruß

[bokel]

Das Problem findet eher zur Laufzeit statt. Wenn ein Listener versucht, sich bei einem Logger anzumelden, der gar nicht existiert. Jetzt, wo ich nochmal drüber nachdenke fällt mir noch ein, dass die Listener den Logger vielleicht pollen könnten, das wäre auch noch eine Möglichkeit, die ohne Tricks bei de Vererbung auskommen würde.

[Janoscharlipp]

Zitat von bokel

Es besteht aus einer statischen Loggerklasse und einige Listenern, die sich automatisch per statischer Initialisierung miteinander verknüpfen sollen, genauer, die Listener sollen sich beim Logger als Listener anmelden.

Heißt dass, dass sowohl der Logger, als auch die Listener auf statischer Ebene funktionieren sollen?

Ich habe gerade glaube ich ein ähnliches Problem:
Ich möchte in der Defaults.as in der statischen setThemeDefaults-Methode Instanzen einiger Klassen in den Styles hinterlegen. Das Problem ist, dass die setThemeDefaults-Methode sehr tricktreich über einen statischen Aufruf ausgeführt wird, somit habe ich die Klassen, von denen ich Instanzen bilden möchte, noch garnicht
Gegenmittel scheint zu sein, Referenzen auf die Klassen in statischen Variablen abzulegen, so macht das Macromedia auch, gefällt mir aber absolut nicht.

[Janoscharlipp]

Aua, grad festgestellt, das obige Lösung nicht mit dem Mtasc funktioniert
So ein Mist, mir fällt echt nicht mehr ein, wie ich das anstellen soll.

Ich schätze fast, dass ich jetzt die Defaults irgendwann ganz normal schreibe, nix mit statisch und so, einfach ein ganz normaler Methodenaufruf.
Ich hoffe die Macromedia-Komponenten machen dann keine Mätzchen.

[artjom]

ich habe diese probleme nicht mehr, seit ich bei einem solchen konzept tage mit fehlersuche verbracht habe. absolut unsinne änderungen (z.b anlegen einer temporären variable, paar leerzeilen zwischen code blöcken) haben dazu geführt, dass die anwendung mal so, mal so arbeitete. (mm entwicklungsumgebung).
es hing irgendwie damit zusammen, dass viele als statisch deklarierte objekte voneinander abhängig waren. so war die kompilierung scheinbar falsch.
...bei sowas kommt mir instant das frühstück hoch

seit ich des nun vermeide und über service klassen löse, funzt jedenfalls alles.

gruß

[bokel]

Ja stimmt, normalerweise vermeide ich auch statische Initialisierungen die von anderen Klassen abhängen. In diesem Fall geht es allerdings nicht anders, weil die Klassen unabhängig voneinander sein sollen.
In meiner letzten Version habe ich es jetzt so gelöst, dass die Klassen ein Interval benutzen, um zu pollen, ob die anderen Klassen da sind.

mfg. r