Hauptmenü

Untermenü

OOP PHP5 - Magische Methoden - Interzeptormethoden

1. Umpf

Jetzt wird es etwas komplizierter. Denn in PHP sind Interzeptormethoden etwas völlig anderes als in anderen Sprachen. In dem Zusammenhang taucht auch immer wieder das Wort "Overloading" (Überladung) auf, das auch hier eine Sonderstellung einnimmt. Ich empfehle daher besonders den Java-Programmierern, im Bezug auf PHP alles zu vergessen, was sie über dieses Thema wissen.

Erklärung

Ich versuche es jetzt mal gaaaanz einfach zu erklären. Auch wenn es möglicherweise nicht ganz korrekt ist. Also, Interzeptormethoden fangen in PHP automatisch fehlerhafte Zugriffe auf Eigenschaften und Methoden einer Klasse ab, die entweder nicht existieren oder nicht über die notwendige Sichtbarkeitsstufe verfügen. Eingesetzt werden sie, um entsprechende Fehlermeldungen zum Beispiel in einem Live-System zu unterdrücken.

2. Das Prinzip

Hierzu greife ich mal auf __call zurück. Dieser Interzeptor wird dann ausgeführt, wenn man keinen Zugriff auf eine Methode hat. In diesem Fall versucht nun das Objekt $waldi die Methode setzGeschlecht aufzurufen. Da die aber außerhalb des Sichtbarkeitsbereiches liegt (private), funktioniert das nicht. Normalerweise fliegt euch nun ein Fatal error: Call to private method Hund::setzGeschlecht() ... um die Ohren. Das wird hier von __call abgefangen und in eine Logdatei geschrieben. Gut, mit den Angaben sollte man ausführlicher sein, aber darum geht es hier nicht. Derselbe Mechanismus greift auch, wenn die Methode nicht vorhanden ist.


class Hund
{
  private $geschlecht;
  
  private function setzGeschlecht($value)
  {
    ...
  }
  public function __call($function$parameter)
  {
    $file   'logfile.log';
    $string date('d.m.Y H:i:s').' Aufruf von '.$function;
    if (count($parameter))
    {
      $string .= ' mit '.count($parameter).' Parameter'."\n";
    }
    file_put_contents ($file$stringFILE_APPEND);    
  }
}
$waldi = new Hund();
$waldi->setzGeschlecht('Männlich');

3. Interzeptoren für Methoden

__call

Habe ich oben schon beschrieben, ich führe es hier nur mal der Vollständigkeit halber auf.


__call (string $funktionsname, array $parameter)

__callStatic

... ist erst seit PHP 5.3 verfügbar und bezieht sich auf statische Methoden. Was das nun schon wieder ist, erkläre ich später.


__callStatic (string $funktionsname, array $parameter)

4. Interzeptoren für Eigenschaften

__get

Wird bei einem Lesezugriff auf eine nicht vorhandene oder nicht zugängliche Eigenschaft ausgelöst.


__get (string $variablenname)

__set

Diese Methode kommt ins Spiel, wenn man schreibenderweise auf eine Eigenschaft zugreifen möchte und es nicht funktioniert.


__set (string $variablenname$wert)

Wichtig!!!

Ich habe schon erlebt, dass Programmierer das ausnutzen, um fehlerhaften Code ein wenig "glatt zu bügeln". Denn hiermit kann man zum Beispiel nicht existente Eigenschaften über diese Fehlerbehandlung erzeugen. Oder den Wert einer Eigenschaft setzen, auch wenn die Sichtbarkeit das nicht zulässt.


class Hund 
{
  public function __set($var$val) 
  {
    $this -> {$var} = $val;
  }
}
$waldi = new Hund;
$waldi -> geschlecht 'männlich';
print_r($waldi);

Finger weg!!!

So was will ich bei euch nicht sehen. Interzeptormethoden sind ausschließlich dazu da, Fehler abzufangen und entsprechend darauf zu reagieren. Sie sind keine Notlösung, um eure eigene Unfähigkeit zu übertünchen!

__isset

... gibt es erst seit PHP 5.1, aber das sollte mittlerweile kein Problem mehr sein. Diese Methode kümmert sich um den fehlerhaften Zugriff auf Eigenschaften per isset. Da man das meiner Meinung nach eh nur in Bedingungen tun sollte, halte ich sie für ziemlich überflüssig.


__isset (string $variablenname)

__unset

... tritt in Aktion, wenn man eine nicht existente oder nicht sichtbare Eigenschaft per unset plätten will.


__unset (string $variablenname)

Wichtig!!!

Hiermit kann man genau so viel Schindluder treiben wie mit __set. Also zum Beispiel von einer Objektreferenz aus eine private Methode künstlich killen. Aber auch hier gilt meine Anweisung(!), dass ihr das nie, nie, niemals machen dürft! Stattdessen solltet ihr lernen, sauber zu programmieren, auf das ihr auf solche Krücken nicht angewiesen seid.

zurück zum vorherigen Abschnitt weiter zum nächsten Abschnitt