Zuweisung eines Objects an ein public static-Attribut

sonicpix · 17.11.2010, 17:07

Hi!

Ich versuche gerade, eine kleine API-Bereinigung in einem Framework zu machen, so dass verschiedene Services über ein Singleton aufgerufen werden, also was man so kennt als

PHP-Code:

  framework::get_instance()->authentication->get_user();

Nun finde ich dies get_instance() hässlich und überflüssig und würde gerne einen Aufruf nach diesem Muster zustandebringen:

PHP-Code:

  framework::$authentication->get_user();

Ich hab dazu in etwa folgende Klasse geschrieben:

PHP-Code:

  class framework

{

    private static $_initialized = false;

 
    public static $authentication;

 
    public static function init()

    {

        if (self::$_initialized)

        {

            return;

        }

        self::$authentication = new framework_authentication();

        self::$_initialized = true;

    }

}

Das Problem ist jetzt, dass mir das einen 500er-Serverfehler unter PHP 5.2.4 liefert. Leider habe ich keinen Zugriff auf die Maschine, kann also nicht ins Log schauen. Aber ich habe festgestellt, dass der Fehler verschwindet, wenn man self::$authentication als private deklariert (wodurch mein Plan aber natürlich nicht funktionieren kann).

Aus dem PHP-Handbuch bin ich nicht wirklich schlau geworden und meine IDE spuckt mir für den obigen Code keinen Fehler aus, daher dachte ich, ich frage mal, ob mir jemand sagen kann ob das Konstrukt so zulässig ist, oer ob das in PHP aus irgendwelchen Gründen nicht erlaubt ist.

nikosch · 17.11.2010, 17:20

Was soll das für einen Sinn haben? Dann musst Du ja stattdessen das init im Vorfeld aufrufen.

500er-Serverfehler haben an sich nichts mit PHP zu tun. Vermutlich liefert Deine Auth-Methode ein unauthorized und fordert selbst diesen 500er Status an.

sonicpix · 17.11.2010, 18:24

Zitat:

Zitat von nikosch

Was soll das für einen Sinn haben? Dann musst Du ja stattdessen das init im Vorfeld aufrufen.

500er-Serverfehler haben an sich nichts mit PHP zu tun. Vermutlich liefert Deine Auth-Methode ein unauthorized und fordert selbst diesen 500er Status an.

Klar muss ich init einmal aufrufen, aber das packe ich einfach im den startup-Code und dann habe ich das auth-Objekt in allen Klassen und Kontexten zur Verfügung, so als ob es ein Superglobal wäre.

Die auth-Klasse, die ich beim Testen benutzt habe, war übrigens leer, d.h. Daran kann es nicht liegen. Der server error tritt auf, sobald ich init aufrufe und verschwindet, wenn ich das auth-Attribut auf private setze, d. h. es hat mit der Sichtbarkeit zu tun, nicht mit der leeren auth-Klasse

nikosch · 17.11.2010, 18:30

Zitat:

Die auth-Klasse, die ich beim Testen benutzt habe, war übrigens leer

Dann kann man darauf auch kein get_user() aufrufen.

Zitat:

so als ob es ein Superglobal wäre

Es ist nicht weniger als genau das. Nur dass Du es als statisches Member tarnst. Genau deswegen ist aus OOP-Sicht die Ursprungsvariante die elegantere.

sonicpix · 17.11.2010, 18:48

Zitat:

Zitat von nikosch

Dann kann man darauf auch kein get_user() aufrufen.

Schon klar. Aber wenn ich bis zum Fatal error method does not exist käme, dann wäre ich ja schon glücklich

Zitat:

Zitat von nikosch

Es ist nicht weniger als genau das. Nur dass Du es als statisches Member tarnst. Genau deswegen ist aus OOP-Sicht die Ursprungsvariante die elegantere.

Naja, die Eleganz liegt im Auge des Betrachters. Aber die spannende Frage ist ja, ob mein Code valides PHP ist und dieser spezielle Server einfach ein Problem hat, oder ob es gar nicht funktionieren kann, weil das so nicht unterstützt wird

nikosch · 17.11.2010, 20:44

500 läuft mir eigentlich nur bei mod rewrite Problemen über den Weg..

Auf Basis des angegebenen Codes kann man IMHO nicht viel sagen..

Chriz · 17.11.2010, 21:24

Zitat:

Zitat von sonicpix

Ich versuche gerade, eine kleine API-Bereinigung in einem Framework zu machen

Du verschlimmbesserst nur.

Zitat:

Das Problem ist jetzt, dass mir das einen 500er-Serverfehler unter PHP 5.2.4 liefert. Leider habe ich keinen Zugriff auf die Maschine, kann also nicht ins Log schauen.

Dann schraub dein error_reporting und display_errors auf sinnvolle Werte.

Zitat:

Aber ich habe festgestellt, dass der Fehler verschwindet, wenn man self::$authentication als private deklariert (wodurch mein Plan aber natürlich nicht funktionieren kann).

Sehe keinen Zusammenhang. Dein Vorhaben ist wie schon erwähnt Murgs. Ja es erscheint einfacher, aber es ist nicht korrekt. Was spricht dagegen, die Instanz an diejenigen Stellen einfach weiterzureichen (über Methodenparameter), anstatt sie sich einfach aus dem nichts zu holen?

sonicpix · 17.11.2010, 23:29

Zitat:

Zitat von Chriz

Du verschlimmbesserst nur.

Naja, sagen wir so: Momentan benutzt das Framework eine in einem Superglobal gespeicherte Instanz, a la

PHP-Code:

  $GLOBALS['framework']->authentication->get_user();

und das finde ich erst recht ne Krücke. Ich könnte jetzt auf framework::get_instance()->authentication->get_user() migrieren, was ich aber auch krampfig finde, oder ich gehe auf meine kürzere Version.

Zitat:

Zitat von Chriz

Dann schraub dein error_reporting und display_errors auf sinnvolle Werte.

Wie im ursprünglichen Post erwähnt habe ich auf diesem speziellen Server keinen Zugriff auf derlei Einstellungen.

Zitat:

Zitat von Chriz

Sehe keinen Zusammenhang. Dein Vorhaben ist wie schon erwähnt Murgs. Ja es erscheint einfacher, aber es ist nicht korrekt. Was spricht dagegen, die Instanz an diejenigen Stellen einfach weiterzureichen (über Methodenparameter), anstatt sie sich einfach aus dem nichts zu holen?

Naja, was ich alternativ überlegt habe, wäre

PHP-Code:

  framework::service('authentication')->get_user();

Aber ich sollte vielleicht etwas weiter ausholen: Mein ursprüngliches Beispiel war stark vereinfacht, in Wahrheit stellt sich die Situation eher so dar:

PHP-Code:

  class framework_main

{

     //eine Handvoll "Unterobjekte" in public properties, z.B.

     public $authentication;

 
     function startup()

     {

         $this->authentication = new framework_authentication();

         //Alternativ auch über magische __get()ter

     }

 
     //ein paar Dutzend Methoden, z.B. 

     public function set_header($name, $string)

    {

        $this->_headers[$name] = $string;

    }

}

 
$GLOBALS['framework'] = new framework_main();

$GLOBALS['framework']->startup();

Ich will da jetzt eine Wrapper-Klasse rumbauen, die in etwa folgendes macht:

PHP-Code:

  class framework

{

     private static $_main;

     

     public static $authentication;

 
     public static init()

     {

         self::$authentication = new framework_authentication(); 

         self::$_main = new framework_main();

         self::$_main->init();

     }

 
     public static set_header($name, $string)

    {

        self::$_main->set_header($name, $string);

    }

}

framework::init();

Stells Dir einfach als eine Variation des Decorator-Patterns vor: Ich habe API, die ich in der Applikation global zur Verfügung gestellt wird. Wie diese API intern umgesetzt wird, ist ein Implementierungsdetail, dass für den Nutzer (d.h. Komponentenentwickler) IMHO nicht relevant ist. In jeden Funktionsaufruf get_instance() (oder wie bisher $GLOBALS['framework']) zu schreiben halte ich einfach für redundant (und schlecht lesbar). Aber wie gesagt, framework::service('identifier')->foo() liesse ich vielleicht noch durchgehen

nikosch · 17.11.2010, 23:44

Zitat:

In jeden Funktionsaufruf get_instance() (oder wie bisher $GLOBALS['framework']) zu schreiben halte ich einfach für redundant (und schlecht lesbar).

Dann schau Dir das DI-Pattern an. Jede Variante von Globals ist schlechter Stil und meist unnötig. Statische Methoden ändern daran auch nichts. Vor allem aber _zerstören_ public Attribute eine Schnittstelle, statt sie zu definieren, erst recht statische. Erst ab PHP 5.3 kann man über das neue static Schlüsselwort damit auch halbwegs im Vererbungskontext arbeiten.

mermshaus · 18.11.2010, 00:44

Ein anderer Ansatz wäre eine Klasse, die den Zugriff auf Bestandteile des Frameworks schöner verpackt (entspricht als Pattern wohl Adapter oder Facade). Von dieser Klasse könnten dann individuelle Komponenten erben.

PHP-Code:

  <?php

abstract class Component
{}

abstract class ComponentFacade extends Component
{
    public function getAuthentication()
    {
        return framework::get_instance()->authentication;
    }

    /* ... */
}

class MyComponent extends ComponentFacade
{}

class MyOtherComponent extends Component
{}

Das liefert dem Komponentenentwickler einen vereinfachten Zugriffslayer, den er nutzen kann (MyComponent), aber den er vielleicht (müsstest du entscheiden) nicht nutzen muss (MyOtherComponent).

Wenn beides zulässig ist, wird allerdings eine gewisse Redundanz/Ambiguität erzeugt, was den Zugriff auf Framework-Bestandteile angeht. Das ist meines Erachtens eher schlecht als gut. Keep it simple.

Edit:

Das ließe sich mit Dependency Injection koppeln.

PHP-Code:

  abstract class ComponentFacade extends Component
{
    protected $framework = null;

    public function __construct(framework $framework)
    {
        $this->framework = $framework;
    }

    public function getAuthentication()
    {
        return $this->framework->authentication;
    }

    /* ... */
}

Wobei da deutlich wird, dass es wenig mehr als ein Alias-Layer ist, um ein wenig Getippe zu sparen.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Exchange 2007 KalenderItems	tarian	PHP-Fortgeschrittene	1	26.05.2010 10:23
[Erledigt] Observer-Pattern	Kardey	Software-Design	20	15.03.2010 17:16
[Erledigt] static Fehler in OOP	abdullah	PHP-Fortgeschrittene	18	03.01.2010 21:05
URL-Design für PAC-Ansatz	xm22	Software-Design	27	02.12.2009 09:38
Decorator-Pattern	grizu	PHP Tipps 2009	15	12.08.2009 14:41
Persistence Framework	#Avedo	Software-Design	37	28.03.2009 17:32
GD-Spezialisten gesucht....wer kann helfen?	rezix	PHP Tipps 2008	12	26.02.2008 17:55

17.11.2010, 17:07
sonicpix Neuer Benutzer Registriert seit: 17.11.2010 Beiträge: 7 PHP-Kenntnisse: Fortgeschritten	Zuweisung eines Objects an ein public static-Attribut Hi! Ich versuche gerade, eine kleine API-Bereinigung in einem Framework zu machen, so dass verschiedene Services über ein Singleton aufgerufen werden, also was man so kennt als PHP-Code: `framework::get_instance()->authentication->get_user();` Nun finde ich dies get_instance() hässlich und überflüssig und würde gerne einen Aufruf nach diesem Muster zustandebringen: PHP-Code: `framework::$authentication->get_user();` Ich hab dazu in etwa folgende Klasse geschrieben: PHP-Code: `class framework { private static $_initialized = false; public static $authentication; public static function init() { if (self::$_initialized) { return; } self::$authentication = new framework_authentication(); self::$_initialized = true; } }` Das Problem ist jetzt, dass mir das einen 500er-Serverfehler unter PHP 5.2.4 liefert. Leider habe ich keinen Zugriff auf die Maschine, kann also nicht ins Log schauen. Aber ich habe festgestellt, dass der Fehler verschwindet, wenn man self::$authentication als private deklariert (wodurch mein Plan aber natürlich nicht funktionieren kann). Aus dem PHP-Handbuch bin ich nicht wirklich schlau geworden und meine IDE spuckt mir für den obigen Code keinen Fehler aus, daher dachte ich, ich frage mal, ob mir jemand sagen kann ob das Konstrukt so zulässig ist, oer ob das in PHP aus irgendwelchen Gründen nicht erlaubt ist.


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

17.11.2010, 17:20
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Was soll das für einen Sinn haben? Dann musst Du ja stattdessen das init im Vorfeld aufrufen. 500er-Serverfehler haben an sich nichts mit PHP zu tun. Vermutlich liefert Deine Auth-Methode ein unauthorized und fordert selbst diesen 500er Status an. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

17.11.2010, 20:44
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	500 läuft mir eigentlich nur bei mod rewrite Problemen über den Weg.. Auf Basis des angegebenen Codes kann man IMHO nicht viel sagen.. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

18.11.2010, 00:44
mermshaus Erfahrener Benutzer Registriert seit: 14.06.2009 Beiträge: 1.731 PHP-Kenntnisse: Fortgeschritten	Ein anderer Ansatz wäre eine Klasse, die den Zugriff auf Bestandteile des Frameworks schöner verpackt (entspricht als Pattern wohl Adapter oder Facade). Von dieser Klasse könnten dann individuelle Komponenten erben. PHP-Code: `<?php abstract class Component {} abstract class ComponentFacade extends Component { public function getAuthentication() { return framework::get_instance()->authentication; } /* ... / } class MyComponent extends ComponentFacade {} class MyOtherComponent extends Component {}` Das liefert dem Komponentenentwickler einen vereinfachten Zugriffslayer, den er nutzen kann (MyComponent), aber den er vielleicht (müsstest du entscheiden) nicht nutzen muss (MyOtherComponent). Wenn beides zulässig ist, wird allerdings eine gewisse Redundanz/Ambiguität erzeugt, was den Zugriff auf Framework-Bestandteile angeht. Das ist meines Erachtens eher schlecht als gut. Keep it simple. Edit: Das ließe sich mit Dependency Injection koppeln. PHP-Code: `abstract class ComponentFacade extends Component { protected $framework = null; public function __construct(framework $framework) { $this->framework = $framework; } public function getAuthentication() { return $this->framework->authentication; } / ... / }` Wobei da deutlich wird, dass es wenig mehr als ein Alias-Layer ist, um ein wenig Getippe zu sparen. __________________ Blog \| Buch \| Kaloa Geändert von mermshaus (18.11.2010 um 02:50 Uhr). Grund: Jetzt ergeben alle Sätze Sinn*