[Stammtisch] Der Unsinn Namens Autoloader

Servus,

ich hatte letztens mal wieder eine interessante Diskussion mit mir selbst und bin zu dem Entschluss gekommen, dass Autoloader etwas sind, was der Entwickler eigentlich nie gebraucht hat!

Ich würde gerne dazu eine Art Stammtisch machen und kucken, was ihr dazu denkt.

Aber ich möchte erst mal dazu kommen, wie ich solch eine gewagte Aussage treffen kann:

Ein Autoloader ist dafür da, eine Klasse nachzuladen, die man während der Laufzeit verwenden möchte.

Jetzt ist natürlich die Frage, ob man nicht eigentlich schon vorher wissen sollte, welche Klassen man verwenden wird.

Eigentlich sollte diese Liste in einem modularen System nicht all zu groß sein und wenn man Stellen hat, an denen man eine Klasse verwendet und nicht sicher ist, ob diese nicht schon geladen ist, hat man eigentlich einen Fehler in seiner Architektur.

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

Ich finde diesen Gedanken eigentlich ziemlich interessant.

Wie denkt ih dazu?

Gruß Sebastian

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.

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.

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

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?

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.

Zitat von floorball92

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?

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

Blödsinn!

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

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

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.

Zitat von floorball92

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; 


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*

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

Peter

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.