hotti: PHP != OOP

Beitrag lesen

Moin,

Es hängt auch ein wenig mit der Syntax zusammen... Mir kommt die PHP-Syntax für OOP immer sehr übetrieben aufgeblasen vor. Da kommt zumindest für mich keine so rechte Motivation auf, objektorientiert zu arbeiten. In JavaScript beispielsweise ist das vollkommen anders. Da wird man ja schon überall wo man schaut mit der Nase auf die OOP hingestoßen. OOP und PHP ist imho ein schwieriges Thema.

Ja, dieses Entweder OOP oder nicht OOP (prozedural) kann ich z.T. nachvollziehen, wenn ich bestimmte Teile der PL-Architektur mit Perl vergleiche.

Was in Perl z.B. möglich ist: Vom prozeduralen Aufbau eines Scripts zu einem objektorientierten Aufbau zu migrieren, Schritt für Schritt. In Perl gibt es immer eine Package namens 'main' (die erbt z.B. von class UNIVERSAL). Jetzt könntest Du z.B. alle Variablen der package 'main' in einer einzigen Referenz {att => 'val'} zusammenfassen, das wäre zunächst ein Datenobjekt. Im nächsten Schritt wird dieses Datenobjekt mit dem Namen einer Klasse gesegnet, z.B. mit dem Namen der Klasse 'main':

my $main = bless{}, 'main';

und aus dem Aufruf von Funktionen

foo(); # entspricht main::foo();

werden Aufrufe von Methoden:

$main->foo();

wobei die Instanz der Klasse 'main' (das $main-Objekt) als erstes Argument übergeben wird. Oft erübrigen sich damit weitere Argumente, denn das $main-Objekt (hier nur als Beispiel für eine Instanz) hat ja Attribute, die womöglich auch an anderer Stelle (andere Methode) gebraucht werden. In den Attributen können weitere Instanzen (anderer Klassen) untergebracht sein, womit sich bestimmte Aufgaben als Methoden delegieren lassen:

  
my $main = bless{  
  FTP => Net::FTP->new(),  
  POP => Mail::POP3->new(),  
  CGI => CGI->new(), # usw.  
}, 'main';  

Was in vielen Fällen eine zweckmäßige Alternative ist: Anstelle einer Mehrfach-Vererbung (main erbt von CGI, Net::FTP, Mail::POP3, ...) wird einfach nur delegiert, ohne ein vogelwildes Klassendesign hinzuwerfen und sich dann überlegen zu müssen, wie die Klassen zusammenwirken sollen, so dass nicht mit grundsätzlichen Regeln der OOP gebrochen wird.

In Perl ist also eine Instanz einer Klasse lediglich eine Referenz die weiß zu welcher Klasse sie gehört. Das hat sehr praktische Konsequenzen zur Folge, die ich in PHP vermisse. Konsequenzen, die für eine wartbare Strukturierung von Code essentiell (lebensnotwendig) sind, z.B. eine saubere Gliederung/Trennung der Namespaces, was mit hunderten Built-in-Funktionen (alle im gleichen Scope) schwierig wird (Btw., in Perl gibt es nur so um die 100 Built-in-Funktionen).

Letztendlich sehe ich das Ziel einer objektorientierten Herangehensweise darin, komplexe Zusammenhänge auf einem einfachen Code abzubilden und nicht noch komplizierter zu machen.

Mehr dazu auf meinem Blog ;)