Eine Klasse in jeder Klasse verfügbar machen

Das Subjekt soll irgendwas loggen.
Dazu bekommt es eine Referenz auf den Observer Überreicht.
Wenn es was zu loggen gibt, schick das Subjekt dem Observer eine Nachricht.

Das Subjekt kann auch ohne Logger überleben.
Es können sich mehrere Logger beim Subjekt eintragen.


Ich sehe da alle Bedingungen für den Einsatz dieses Pattern erfüllt.

Aber der TO will "in jeder Datei" (lies Klasse) Zugriff auf den Logger haben. Dafür müßte jedes Objekt observiert werden. Um das sauber umzusetzen, müsste jede Klasse mit implements/extends Observable versehen werden und nach jeder Konstruktion eines Objekts muss der Logger als Observer gesetzt werden.

Wenn sich ein Pattern über absolut alle Klassen erstreckt, hat man garantiert was falsch gemacht!

Wie auch immer....
Trotz der spärlichen Angaben des TE sind hier 3 Wege aufgetaucht:
1. Globale Variablen
2. Singleton (oder einfache statische Variablen)
3. Subjekt-Observer

Alle drei haben so ihre spezifischen Vor und Nachteile. Wobei für mich die Nachteile von 1 und 2 überwiegen. Auch sehe ich keine Notwendigkeit, jede Klasse mit diesem Interface auszustatten.

Dank meiner eigenen (teilweise bitteren) Erfahrungen, werde ich niemals "bau es als Singleton" sagen.
Immer nur davon abraten. Und: Es gibt immer Alternativen.

Zitat von combie

Dank meiner eigenen (teilweise bitteren) Erfahrungen, werde ich niemals

Und ich würde lieber erstmal sagen: Eins nach dem andern. Schau dir mal die Threads des TOs an. Schau dir die Fragen an. Und dann leite daraus den Kenntnisstand ab.

Und dann leite daraus den Kenntnisstand ab.

Möchtest du diesen Stand festigen, oder Stoff zur Weiterentwicklung liefern?
Gerade jemanden, mit niedrigem Kenntnisstand sollte man nicht auf Irrwege schicken. Und Singleton ist (erstaunlich häufig) ein Irrweg.
Der TE möchte sich mit Klassen/OOP beschäftigen. Dazu gehört auch die Anwendung der Design Pattern. Ob beabsichtigt, oder nicht. Ob angelesen, oder selbst entwickelt.

Was von mir als sinnvoller/witziger Wink von der Seite gedacht war, wird jetzt zum Problem. Zum Prüfstein. Naja....
Welches Mittel oder welcher Weg von irgendwem genutzt wird, da habe ich sowieso keinen Einfluss.

Zitat von combie

Möchtest du diesen Stand festigen, oder Stoff zur Weiterentwicklung liefern?
Gerade jemanden, mit niedrigem Kenntnisstand sollte man nicht auf Irrwege schicken. Und Singleton ist (erstaunlich häufig) ein Irrweg.
Der TE möchte sich mit Klassen/OOP beschäftigen. Dazu gehört auch die Anwendung der Design Pattern. Ob beabsichtigt, oder nicht. Ob angelesen, oder selbst entwickelt.

Und ob es einem gefällt oder nicht, aber das Singleton gehört zu den Design-Pattern, wenn man die GoF als Referenz nimmt. Das auszublenden wäre IMHO gefährlicher, wenn man möchte, dass sich der TO weiterentwickelt. Und ich habe ihm neue Wege aufgezeigt, die ihn weiterbringen würden …*du willst nur, dass er sofort den (jedenfalls deiner Meinung nach) besten geht. Und das halte ich zum jetzigen Zeitpunkt für verfrüht. Es sei denn, du möchtest hier einen kostenlosen Power-Workshop machen um die dutzenden F'ups zu beantworten. Da hab ich nämlich keine Lust drauf –*allein weil es dazu auch noch nicht von Erfolg gekrönt sein wird.

Und ob es einem gefällt oder nicht, aber das Singleton gehört zu den Design-Pattern, wenn man die GoF als Referenz nimmt.

Auch diese sind keine Götter.
Und ich vermute mal, dass sie sich seit Jahren schon dafür in den Hintern beißen, das sie das aufgenommen haben. Nicht umsonst ist es in der Gemeinde als Anti Pattern verschrieen.

Auch wenn ich mich hier wie ein Priester aufführe: Die Nachteile überwiegen.

Beinahe zwangsläufig:

PHP-Code:

class irgendeine
{
 public function tuwas()
 {
   // hier tut die Methode ganz was wichtiges
  Mein_Logger::getInstance()->log('Hi, habe gerade ganz was wichtiges getan!');
 }
} 


Es wird der Tag kommen, da soll der Logger ausgewechselt werden. Oder einfach nur weggelassen. Dank der starken Abhängigkeit müssen alle betreffenden Klassen überarbeitet werden.

Auch ein Drama:
Von Singleton Klassen kann man nicht ableiten. Auch in PHP5.3 nur sehr unsauber. Ist es sinnvoll sich dieser Möglichkeit zu berauben?

Wenn man mit Design Pattern arbeitet, dann ist Mein_Logger ohnehin nur eine Fassade … und somit alles dahinterliegende ohne weiteres austauschbar.

Aber offensichtlich willst du meine Beweggründe auch gar nicht verstehen …

Zitat von combie

Von Singleton Klassen kann man nicht ableiten. Auch in PHP5.3 nur sehr unsauber.

Nicht dass ich Singletons gutheißen würde, aber was meinst du damit? In PHP5.3 ist es nur ein einziges self, dass man durch static austauscht. Warum ist das unsauber?

Edit: achso, ich ziehe die Frage zurück, bin grad selbst drauf gekommen

Naja..
Ich finde den Umweg über get_called_class() und dem statischen Array nicht hübsch.

PHP-Code:

abstract class Singleton
{
    private static $instances= array();
    
    final public static function getInstance()
    {
      $class = get_called_class();
      if(empty(self::$instances[$class]))
        self::$instances[$class] = new $class;
      return self::$instances[$class];
    }

    protected function __construct(){}
    final private function __clone(){}
}


class mytest extends Singleton
{

}

$my = MyTest::getInstance();

echo get_class($my); 


Aber wer weiß...
Wenn du einen schöneren Weg kennst....
*verharre in freudiger Erwartung*

Edit:

achso, ich ziehe die Frage zurück,

zu spät gesehen.

Singleton instanziert sich somit selber und gibt die Referenz zurück.
Das wäre doch schonmal eine Lösung, dass ich nicht überall nochmals instanzieren muss, sondern einfach eine statische Methode anspreche.