Objekt global bereitstellen

[Seb]

Hi,

das macht mich echt verrückt...

Ich habe eine Error Klasse; von dieser erstelle ich ein Objekt in $e

Jetzt möchte ich der kompletten Application das Objekt $e bereitstellen, sodass jede Klasse den Error Handler verwedenen kann.

Aber ich möchte halt nicht in jeder Methode, in der der Error Handler benötigt wird, ein global $e; schreiben, gibt es nicht einen besseren Weg?

Gruß Sebastian

[Felix Riesterer]

Lieber Seb,

Aber ich möchte halt nicht in jeder Methode, in der der Error Handler benötigt wird, ein global $e; schreiben, gibt es nicht einen besseren Weg?

$GLOBALS['e'] vielleicht?

Liebe Grüße,

Felix Riesterer.

[Multi]

Mahlzeit,

Jetzt möchte ich der kompletten Application das Objekt $e bereitstellen, sodass jede Klasse den Error Handler verwedenen kann.

Eine Möglichkeit wäre, wenn du einfach die Error-Klasse erweiterst.

class NeueKlasse extends ErrorKlasse {...

dann sind die Methoden des Errorhandlings auch Methoden der Klasse selbst

EIne andere Methode wäre ein Singleton, da wird entweder eine neue Instanz angelegt oder eine alte benutzt, falls es eine gibt.

[Sven Rautenberg]

Moin!

das macht mich echt verrückt...

Ich habe eine Error Klasse; von dieser erstelle ich ein Objekt in $e

Jetzt möchte ich der kompletten Application das Objekt $e bereitstellen, sodass jede Klasse den Error Handler verwedenen kann.

Aber ich möchte halt nicht in jeder Methode, in der der Error Handler benötigt wird, ein global $e; schreiben, gibt es nicht einen besseren Weg?

Globale Variablen sind eine schlechte Idee - auch in OOP. :)

Die Frage ist, warum du auf diese Lösung mit dem globalen Objekt gekommen bist, und welche Alternativen es gibt. Denn es gibt immer Alternativen, es hängt nur davon ab, wie aufwendig die zu realisieren sind, allgemein betrachtet und ausgehend von deinem jetzigen Code.

Deshalb mal zur Beleuchtung: Was macht deine Error-Klasse? Warum muss sie ein globales Objekt sein?

Der Zugriff auf $GLOBALS ist jedenfalls keine wirkliche Alternative zu "global $e", das ist effektiv dasselbe.

Jede Klasse die Fehlerklasse erweitern zu lassen ist auch keine gute Idee, da die Vererbung eventuell ja schon von einer anderen Klasse genutzt wird - und PHP kennt eben keine Mehrfachvererbung.

Das Stichwort Singleton wurde genannt, aber ich halte es ohne genauere Kenntnis des Grundes, warum das Errorobjekt global sein soll, für keine gute Alternative. Wenn sich der Grund der Globalität eliminieren lässt, entfällt auch die Notwendigkeit für ein Singleton, das ist im Endeffekt die bessere Wahl.

Statische Aufrufe der Klassenmethoden wären noch eine Möglichkeit, aber auch das ist nicht ganz so schön, wie es auf den ersten Blick aussieht. Statt der globalen Variable festen Namens, die in allen Klassen einprogrammiert und genutzt werden muss, sind statische Aufrufe einfach nur eine andere Form desselben Problems: Jetzt muss man eben die fest definierten Klassenmethodennamen aufrufen.

Vernünftig wäre eine Lösung, die jedem Objekt, ggf. im Konstruktor, eine Referenz auf das im globalen Namespace angelegte Error-Objekt übergibt.

- Sven Rautenberg

[Seb]

»» Deshalb mal zur Beleuchtung: Was macht deine Error-Klasse? Warum muss sie ein globales Objekt sein?

Die Funktion der Error Klasse besteht darin, bestimmte Fehler während ablauf in der Application gemeldet werden, dann gibt die Error Klasse Fehler aus, andere Klassen können aber auch bei Warnings erfragen und somit schauen, in wiefern ein weiterer Ablauf der Application möglich ist.

Also Fehler empfangen, ausgeben, weitergeben

Gruß Sebastian

[Sven Rautenberg]

Moin!

»» Deshalb mal zur Beleuchtung: Was macht deine Error-Klasse? Warum muss sie ein globales Objekt sein?

Die Funktion der Error Klasse besteht darin, bestimmte Fehler während ablauf in der Application gemeldet werden, dann gibt die Error Klasse Fehler aus, andere Klassen können aber auch bei Warnings erfragen und somit schauen, in wiefern ein weiterer Ablauf der Application möglich ist.

Also Fehler empfangen, ausgeben, weitergeben

Das ist als Beschreibung etwas dünn.

Allerdings kann ich nicht erkennen, warum es dazu ein globales Fehlerobjekt geben muss. Üblicherweise würde man sowas entweder durch das Werfen passender Exceptions lösen, oder - nicht jeder findet Exceptions den idealen Weg - durch Rückgabe passender Objekte bzw. Ergebnisse: Im erfolgreichen Ausführungsfall eben die Daten, im fehlerhaften Ausführungsfall eine Instanz einer Fehlerklasse.

Ganz trivial löst PHP es selbst z.B. bei den MySQL-Funktionen: Wenn irgendwas falsch läuft, wird anstelle einer Ressource einfach "false" zurückgegeben, und die näheren Fehlerumstände lassen sich durch eine Fehlerabfragefunktion ermitteln. Wenn man sich das für MySQLi mal genauer anschaut: Die DB-Connection bildet ein Objekt, welches z.B. für die Methode "query" ein false zurückgeben kann, der Fehler ist dann durch die Methode "error" zu erfahren.

- Sven Rautenberg

[Joachim]

Hi,

Aber ich möchte halt nicht in jeder Methode, in der der Error Handler benötigt wird, ein global $e; schreiben, gibt es nicht einen besseren Weg?

Übergabe als Referenz?

$error = new handle_error();

class foobar {
    function foobar(&$error) {
        .
        .
        .
        $error->add(ERROR_WRONG_PASS);
    }
}

Gruesse, Joachim

[Sympathisant]

Hai,

FYI:
Mir ist nicht ganz ersichtlich was deine Error-Klasse alles realisieren soll. Aber es hoert sich doch stark nach Loggin an. Wenn dies der Fall ist, dann duerfte wohl auch folgendes Projekt fuer dich interessant sein:
Log4Php
Kannst ja mal dort schauen wie die das realisiert haben.

MfG,
Sympatisant