[Stammtisch] Der Unsinn Namens Autoloader

**onemorenerd** · 02.05.2010, 12:07

Ein Autoloader erspart dem Entwickler das Verkleckern von require_once-Anweisungen über die ganze Applikation.
Deshalb muss er auch nicht wissen, wo Klassen liegen.
Das wiederum gestattet es, die Klassen zu verschieben und nur an einer Stelle, dem Autoloader, Code anpassen zu müssen.

**floorball92** · 02.05.2010, 12:32

Was wiederum wieder die Frage aufkommen lässt, ob man sich vorher nicht genug Gedanken gemacht hat... Und in den meisten Systemen wird auch eine Namenskonvention wie in PEAR verwendet, wo Klassenname und Pfad zur Datei verknüpft sind, sodass dort dieses Argument ebenfalls nicht greift.

**onemorenerd** · 02.05.2010, 12:40

Was hat das denn damit zu tun, ob man sich vorher Gedanken gemacht hat? Ich kann deiner Argumentation nicht folgen.

**h3ll** · 02.05.2010, 12:43

Ein Autoloader ladet genau die Dateien, die man auch wirklich braucht. Gäbe es keinen Autoloader, müsste man sich ständig Gedanken machen, was jetzt geladen werden soll und was nicht. Im Zweifel wird dann einfach zuviel geladen, statt zu wenig, was wieder die Performance drückt. Außerdem nimmt ein Autoloader sehr viel Tipparbeit ab.

Stell dir vor, du programmierst in einer Klasse, die andere Klassen benötigt. Jetzt entfernst du einen bestimmten Code-Teil, weil er nicht mehr benötigt wird. In diesem Code-Teil wurde eine bestimmte Anzahl an Klassen verwendet. Du müsstest jetzt den kompletten Code von oben bis unten durchgehen und schauen, ob die Klassen sonst noch wo benötigt werden. Wenn ja, dann musst du das require_once im Code lassen, wenn nicht, musst du es entfernen. Wozu sich die ganze unnötige Arbeit selber antun?

**floorball92** · 02.05.2010, 14:34

Mit einer entsprechend guten Architektur hast du die Probleme aber nicht. Beispiel ist z.B. Zend. Im Zend FW wird auch am Anfang jeder Klasse alles manuell geladen.

**h3ll** · 02.05.2010, 14:43

Zitat von floorball92 Beitrag anzeigen

Mit einer entsprechend guten Architektur hast du die Probleme aber nicht. Beispiel ist z.B. Zend. Im Zend FW wird auch am Anfang jeder Klasse alles manuell geladen.

Wenn die Architektur so gut ist, warum ist dann Zend dabei das FW auf Autoload umzubauen?

**combie** · 02.05.2010, 15:05

Ist ein Autoloader also nur für Leute da, die sich vorher zu wenig Gedanken über ihr gesamt Konzept gemacht haben?

Blödsinn!

**AmicaNoctis** · 02.05.2010, 22:25

Hallo,

hier noch mein Senf. Ich finde das Autoloading-Konzept der SPL toll. Die magische __autoload-Funktion konnte mich nie überzeugen, aber seit dem SPL-Autoloader mache ich jetzt alles darüber, zumal ich seit PHP 5.3 meine Klassen in Namespaces organisiere und ähnlich zu Java-Code mit use arbeiten kann, um andere Klassen zu importieren - und das ohne

ewig lange absolute Pfade anzugeben
abwärtskompatible relative Pfadangaben (dirname(__FILE__) . "/relativer/Pfad.php") machen zu müssen

PHP-Code:


namespace foo|bar;
use xyz|SomeClass;
use abc|def|SomeInterface;
class Example extends SomeClass implements SomeInterface { ... }

(Das Forum akzeptiert keinen Backslash im PHP-Code, daher musste ich | nehmen.)

Einfach toll! Diese Sauberkeit soll mir mal jemand mit require_once vormachen.

Gruß,

Amica

**combie** · 03.05.2010, 08:59

Schön argumentiert.
Aber auf Grund der polemischen Fragestellung würde ich keine Einsicht erwarten.

**floorball92** · 03.05.2010, 16:58

Hätte eigentlich erwartet, dass ich nicht ganz der einzige bin, der darüber mal nachgedacht hat und gewisse Argumente gegen den Autoloader dabei anerkannt hat.

Ich sage auch nicht, dass Autoloader schlecht sind, ich benutze ja selbst oft den SPL Autoloader, aber ich finde die Argumente gegen den Autoloader trotzdem sinnvoll und werde auch nach wie vor in Zukunft immer überlegen, ob ich einen Autoloader wirklich brauche.

Und noch mal von wegen undurchsichtiger Dokumentierung, wenn ich mein File habe, dort erst Dateikommentar, require_once Anweisungen, Klassenkommentar Klasse finde ich auch meinen Programm Code oder eher gesagt die eigentliche Logik vom einbinden sehr gut separiert.

In C++ wird es ja auch nicht anders gemacht.

**h3ll** · 03.05.2010, 17:09

Zitat von floorball92 Beitrag anzeigen

Und noch mal von wegen undurchsichtiger Dokumentierung, wenn ich mein File habe, dort erst Dateikommentar, require_once Anweisungen, Klassenkommentar Klasse finde ich auch meinen Programm Code oder eher gesagt die eigentliche Logik vom einbinden sehr gut separiert.

Ist das dann nicht aber ein wenig doppelt gemoppelt? Also mir wär es zu blöd, alles doppelt schreiben zu müssen:

PHP-Code:


require_once 'library/foo.php';
require_once 'domain/bar.php';

use library|foo;
use domain|bar;

**combie** · 03.05.2010, 17:11

Hätte eigentlich erwartet, dass ich nicht ganz der einzige bin, der darüber mal nachgedacht hat und gewisse Argumente gegen den Autoloader dabei anerkannt hat.

Es gibt kein Argument gegen SPL Autoload!
Zumindest habe ich noch keins gehört.
Auch du hast keins gebracht.
Denn:

Ist ein Autoloader also nur für Leute da, die sich vorher zu wenig Gedanken über ihr gesamt Konzept gemacht haben?

*entschärft*
Man könnte sich darüber unerhalten, ob die SPL Autoload Implementierung optimal ist, was man noch verbessern könnte, usw...
*entschärft*

**Kropff** · 03.05.2010, 17:51

Ab sofort herrscht hier wieder ein gemäßigter Ton. Sonst mache ich Thread dicht!

Peter

**PHP-Desaster** · 03.05.2010, 22:04

Das einzige - wohl eher an den Haaren herbeigezerrte und nicht von mir unterstützte - Argument gegen Autoloading wäre der Aufwand, die Autoloadfunktion bei jeder fehlenden Klasse aufzurufen. Dieser ist allerdings minimal. Da überwiegt die Entwicklungszeit, die require-Anweisungen korrekt zu setzen ganz bestimmt und die eingeschränkte Flexibilität gegenüber dem Autoloading.

[Stammtisch] Der Unsinn Namens Autoloader