Dieser Artikel ist hauptsächlich eine Zusammenfassung der automatischen Ladefunktion von PHP und behandelt die automatische Ladefunktion von PHP, den PHP-Namespace, die PSR0- und PSR4-Standards von PHP usw. Ich hoffe, es hilft allen.

1. PHP-Autoladefunktion

Der Ursprung der PHP-Autoladefunktion

Wenn Sie in PHP während des Entwicklungsprozesses eine Klasse von außen einführen möchten, verwenden Sie normalerweise die Methoden include und require, um die Datei einzuschließen, die die Klasse definiert. Wenn dies im kleinen Maßstab entwickelt wird, gibt es kein großes Problem. In großen Entwicklungsprojekten bringt die Verwendung dieser Methode jedoch einige versteckte Probleme mit sich: Wenn eine PHP-Datei viele andere Klassen verwenden muss, sind viele Require/Include-Anweisungen erforderlich, was zu Auslassungen oder Einschlüssen unnötiger Klassendateien führen kann . Wenn eine große Anzahl von Dateien die Verwendung anderer Klassen erfordert, ist es ein Albtraum, sicherzustellen, dass jede Datei die richtige Klassendatei enthält, und require_once ist teuer.

PHP5 bietet eine Lösung für dieses Problem, nämlich den Autoload-Mechanismus von Klassen. Der Autoload-Mechanismus ermöglicht es PHP-Programmen, Klassendateien nur dann automatisch einzubinden, wenn Klassen verwendet werden, anstatt alle Klassendateien von Anfang an einzubinden. Dieser Mechanismus wird auch als Lazy Loading bezeichnet.

Zusammenfassend lässt sich sagen, dass die automatische Ladefunktion mehrere Vorteile mit sich bringt:

1. Sie müssen die nicht verwenden Klasse vor „Einschließen“ oder „Anfordern“

2. erfordert/einschließt nur Dateien, wenn Klassen verwendet werden, wodurch verzögertes Laden implementiert wird und das Erfordern/Einschließen redundanter Dateien vermieden wird.

3. Es besteht keine Notwendigkeit, die tatsächliche Festplattenadresse der eingeführten Klasse zu berücksichtigen, um die Trennung von logischen und physischen Dateien zu realisieren.

  
Wenn Sie mehr über die automatische Ladefunktion im Detail erfahren möchten, können Sie sich die Informationen ansehen:
PHPs Klasse automatischer Lademechanismus
Implementierungsanalyse des PHP-Autoload-Mechanismus

PHP automatische Ladefunktion __autoload()

Wenn PHP5 normalerweise feststellt, dass die Klasse nicht geladen ist, führt es automatisch die Funktion _autoload() aus. Diese Funktion wird von uns im Programm angepasst erforderliche Klasse zur Verwendung. Das Folgende ist ein einfaches Beispiel:

<span style="font-size: 14px;">function __autoload($classname) {    require_once ($classname . "class.php"); <br>}<br></span>

In unserem einfachen Beispiel fügen wir den Klassennamen direkt zur Erweiterung „.class.php“ hinzu, um den Klassendateinamen zu bilden Verwenden Sie require_once, um es zu laden. Aus diesem Beispiel können wir ersehen, dass Autoload mindestens drei Dinge tun muss:

1. Bestimmen Sie den Klassendateinamen basierend auf dem Klassennamen

2. Bestimmen Sie den Festplattenpfad, in dem sich die Klassendateien befinden (in unserem Fall befinden sich die Klassen im einfachsten Fall im selben Ordner wie die PHP-Programmdateien). Rufen Sie sie auf);

3. Lädt Klassen aus Festplattendateien in das System.

 Der dritte Schritt ist der einfachste, verwenden Sie einfach include/require. Um die Funktionen des ersten und zweiten Schritts zu realisieren, muss während der Entwicklung die Zuordnungsmethode zwischen dem Klassennamen und der Festplattendatei vereinbart werden. Nur so können wir die entsprechende Festplattendatei anhand des Klassennamens finden.

Wenn eine große Anzahl von Klassendateien einbezogen werden muss, müssen wir nur die entsprechenden Regeln ermitteln und dann in der Funktion __autoload() den Klassennamen mit dem tatsächlichen abgleichen Festplattendatei, Sie können den Effekt des verzögerten Ladens erzielen. Hier können wir auch erkennen, dass das Wichtigste bei der Implementierung der Funktion _autoload() die Implementierung der Zuordnungsregeln zwischen dem Klassennamen und der tatsächlichen Festplattendatei ist.

Probleme mit der Funktion __autoload()

Wenn Sie bei der Implementierung eines Systems viele andere Klassenbibliotheken verwenden müssen, sind diese Klassenbibliotheken können von verschiedenen Entwicklern geschrieben sein und unterschiedliche Zuordnungsregeln zwischen Klassennamen und tatsächlichen Festplattendateien haben. Wenn Sie zu diesem Zeitpunkt das automatische Laden von Klassenbibliotheksdateien implementieren möchten, müssen Sie alle Zuordnungsregeln in der Funktion __autoload() implementieren. In diesem Fall ist die Implementierung der Funktion autoload() möglicherweise sehr kompliziert oder sogar unmöglich. Am Ende kann die Funktion autoload() sehr aufgebläht werden. Selbst wenn sie implementiert werden kann, wird sie sich stark negativ auf die zukünftige Wartung und Systemeffizienz auswirken.

Wo liegt also das Problem? Das Problem besteht darin, dass _autoload() eine globale Funktion ist, die nur einmal definiert werden kann und nicht flexibel genug ist. Daher müssen alle logischen Regeln, die Klassennamen und Dateinamen entsprechen, in einer Funktion implementiert werden, was dazu führt, dass diese Funktion aufgebläht wird. Wie kann man dieses Problem lösen? Die Antwort besteht darin, einen _autoload-Aufrufstapel zu verwenden, verschiedene Zuordnungsbeziehungen in verschiedene _autoload-Funktionen zu schreiben und diese dann einheitlich zu registrieren und zu verwalten. Dies ist das in PHP5 eingeführte SPL-Autoload.

SPL Autoload

SPL ist die Abkürzung für Standard PHP Library. Es handelt sich um eine in PHP5 eingeführte Erweiterungsbibliothek. Zu ihren Hauptfunktionen gehört die Implementierung des Autoload-Mechanismus und verschiedener Iterator-Schnittstellen oder -Klassen. SPL Autoload hat mehrere spezifische Funktionen:

1. spl_autoload_register: Registrieren Sie die __autoload()-Funktion

2. spl_autoload_unregister: Registrierung registrierter Funktionen aufheben

3. spl_autoload_functions: Alle registrierten Funktionen zurückgeben

4. spl_autoload_call: Probieren Sie alle registrierten Funktionen aus, um eine Klasse zu laden

5. spl_autoload: Standardimplementierung von __autoload()

6. spl_autoload_extensions: Registrieren Sie die von der spl_autoload-Funktion verwendeten Standarddateierweiterungen und geben Sie sie zurück.

 
Die detaillierte Verwendung dieser Funktionen finden Sie in der ausführlichen Erklärung von spl_autoload in PHP

Einfach: spl_autoload ist die von SPL selbst definierte Funktion __autoload(). Die Funktion besteht darin, in das registrierte Verzeichnis (festgelegt durch set_include_path) zu gehen, um die .php/.inc-Datei mit demselben Namen wie $ zu finden Klassenname. Natürlich können Sie durch die Registrierung von Erweiterungen (spl_autoload_exionsions) auch bestimmte Dateitypen angeben.

Und spl_autoload_register() ist der oben erwähnte Autoload-Aufrufstapel. Wir können mehrere unserer eigenen _autoload()-Funktionen für diese Funktion registrieren. Wenn PHP den Klassennamen nicht finden kann, ruft PHP den benutzerdefinierten auf _autoload() Funktion nacheinander, um die automatische Ladefunktion zu implementieren. Wenn wir in diese Funktion keine Parameter eingeben, wird die Funktion spl_autoload() registriert.

Okay, das ist die unterste Ebene des automatischen Ladens von PHP. Der Registrierungsmechanismus ist bereits sehr flexibel, aber was fehlt? Wie oben erwähnt, ist der Schlüssel zum automatischen Laden die Zuordnung von Klassennamen und Dateien. Diese Zuordnungsbeziehung ist sehr flexibel, aber wenn sie zu flexibel ist, wirkt sie etwas chaotisch Spezifikation für diese Zuordnungsbeziehung, die im Standard PSR PSR0 und PSR4 ist.

Aber bevor wir über PSR0 und PSR4 sprechen, müssen wir auch das Problem des PHP-Namespace verstehen, da diese beiden Standards eigentlich nicht auf die Zuordnung von Klassennamen und Verzeichnisdateien abzielen, sondern Ist die Zuordnung von Namespaces und Dateien. Warum passiert das? Nach meinem Verständnis ist der Namespace in gewisser Weise ein Alias ​​​​des Klassennamens. Warum sollten wir den Namespace einführen und welche Vorteile hat der Namespace? 🎜>2. Namespace

In PHP werden Namespaces verwendet, um zwei Arten von Problemen zu lösen, die beim Erstellen von wiederverwendbarem Code wie Klassen oder Funktionen beim Schreiben von Klassenbibliotheken oder Anwendungen auftreten:

1 Vom Benutzer geschriebener Code und PHP-interne Klassen Namenskonflikte zwischen /functions/ Konstanten oder Klassen/Funktionen/Konstanten von Drittanbietern2 Erstellen Sie einen (oder kurzen) Namen für einen sehr langen Bezeichnernamen (normalerweise definiert, um die erste Art von Problem zu lindern), und verbessern Sie die Lesbarkeit des Quellcodes.
PHP-Namespaces bieten eine Möglichkeit, verwandte Klassen, Funktionen und Konstanten zu gruppieren.

   
Um es einfach auszudrücken: PHP erlaubt keine zwei Klassen, Funktionen oder Variablennamen mit demselben Namen im Programm. Dann werden einige Leute verwirrt sein und sie können nicht dasselbe haben Name. Ist das nicht genug? Tatsächlich sind viele große Programme auf viele Bibliotheken von Drittanbietern angewiesen. Dies ist das erste Problem auf der offiziellen Website. Wie kann man dieses Problem lösen? Wenn kein Namespace vorhanden ist, kann der arme Programmierer nur den Klassennamen a_b_c_d_e_f angeben, wobei a/b/c/d/e/f im Allgemeinen eine eigene spezifische Bedeutung hat, sodass im Allgemeinen keine Konflikte auftreten, sondern lange Klassennamen sind ermüdend beim Schreiben und noch unangenehmer beim Lesen. Daher hat PHP5 den Klassennamen eingeführt, und der Namespace ist der Namespace. Beim Schreiben/Lesen des Programms wird der Klassenname direkt verwendet, wodurch das Problem gelöst wird.

Darüber hinaus bieten Namespaces eine Möglichkeit, verwandte Klassen, Funktionen und Konstanten zu gruppieren. Dies ist auch eine großartige Verwendung von objektorientierten Sprachnamensräumen. Klassen, Variablen und Funktionen, die für bestimmte Zwecke erforderlich sind, werden in einen Namensraum geschrieben und gekapselt.

Nachdem wir das Problem der Klassennamen gelöst haben, können wir endlich zum PSR-Standard zurückkehren. Wie standardisieren PSR0 und PSR4 also die Zuordnungsbeziehung zwischen Dateien und Namespaces? Die Antwort lautet: Einschränkungen bei der Benennung des Namespace (naja, es ist etwas verwirrend), dem Speicherort des Klassendateiverzeichnisses und der Zuordnungsbeziehung zwischen den beiden. Dies ist der Kern des Standards. Eine ausführlichere Beschreibung finden Sie in Modern PHP New Feature Series (1) – Namespace

3. PSR-Standard

ist Apropos PSR0 und PSR4: Lassen Sie uns den PSR-Standard vorstellen. Der Erfinder und Standardisierer des PSR-Standards ist: PHP-FIG, und seine Website ist: www.php-fig.org. Es war dieses Konsortium, das die PSR-Spezifikation erfunden und erstellt hat. FIG ist die Abkürzung für Framework Interoperability Group. Sie wurde 2009 von mehreren Open-Source-Framework-Entwicklern gegründet. Obwohl es sich nicht um eine „offizielle“ Organisation handelt, repräsentiert sie auch einen großen Teil der Community . Der Zweck der Organisation besteht darin, die Codierungsstandards jedes Projekts mit den geringsten Einschränkungen zu vereinheitlichen, um zu vermeiden, dass der eigene Entwicklungsstil jedes Unternehmens die Entwicklung von Programmdesignern behindert. Daher hat jeder PSR erfunden und zusammengefasst. PSR schlägt eine Standardempfehlung vor (Proposing a Standards Recommendation) Abkürzung für Standards Proposal.

Detaillierte Spezifikationen und Standards finden Sie unter
PSR-Spezifikationen in PHP

PSR0-Standard

Die PRS-0-Spezifikation ist der erste von ihnen herausgegebene Satz von Spezifikationen, der hauptsächlich einige Standards für das automatische Laden formuliert (Autoloading-Standard). PSR-0 Mandatory Mehrere Anforderungen:

1. Ein vollständig qualifizierter Namespace und eine Klasse müssen dieser Struktur entsprechen: „< Vendor Name>(< Namespace>)*< Class Name>“
2. Jeder Namespace muss einen Namensraum der obersten Ebene haben („Anbietername“).
3 Jeder Namespace kann mehrere Unternamensräume haben.
4. Das Trennzeichen (/) jedes Namespace muss in DIRECTORY_SEPARATOR (Betriebssystempfadtrennzeichen) umgewandelt werden
5. Im Klassennamen muss jedes Unterstrichsymbol (_) in DIRECTORY_SEPARATOR (Betriebssystempfadtrennzeichen) umgewandelt werden. Innerhalb eines Namensraums hat das Symbol underscore_ keine (besondere) Bedeutung.
6. Beim Laden aus dem Dateisystem müssen der qualifizierte Namespace und die Klasse mit .php enden.
7. Verdor-Name, Namespaces und Klassennamen können aus Groß- und Kleinbuchstaben bestehen (Groß- und Kleinschreibung beachten)

  
Die spezifischen Regeln können etwas verwirrend sein, also fangen wir von vorne an.

Werfen wir zunächst einen Blick auf den allgemeinen Inhalt des PSR0-Standards. Die Artikel 1, 2, 3 und 7 legen Beschränkungen für die Namen von Namespaces fest, und die Artikel 4 und 5 legen die Zuordnungsbeziehung zwischen Namespaces und fest Dateiverzeichnisse Es gibt Einschränkungen, Artikel 6 ist der Dateisuffixname.
 
Wie bereits erwähnt, wie standardisiert der PSR-Standard die Zuordnungsbeziehung zwischen dem Namespace und dem Dateiverzeichnis, in dem er sich befindet? Dies geschieht durch Einschränkung des Namens des Namespace, des Speicherorts des Dateiverzeichnisses und der Zuordnungsbeziehung zwischen beiden.
 
Dann müssen wir uns vielleicht fragen: Wo ist die Beschränkung für den Speicherort des Verzeichnisses, in dem sich die Datei befindet? Tatsächlich lautet die Antwort:
  

Namespace-Namen einschränken + Zuordnung von Namespace-Namen und Dateiverzeichnis einschränken = Dateiverzeichnis einschränken

 
Okay, lassen Sie uns zunächst darüber nachdenken: Welche Anpassungen müssen für ein bestimmtes Programm vorgenommen werden, wenn es den PSR0-Standard unterstützen möchte?

1. Zuerst muss das Programm eine Zuordnungsfunktion definieren, die den Artikeln 4 und 5 des PSR0-Standards entspricht, und diese Funktion dann in spl_register( );

2. Zweitens müssen beim Definieren eines neuen Namespace der Name des Namespace und der Verzeichnisspeicherort der Datei den Punkten 1, 2, 3 und 7 entsprechen.

 
Im Allgemeinen definieren wir zur Vereinfachung der Codewartung nur einen Namespace in einer Datei.
 
Okay, wir haben den Namen des Namespace, der dem PSR0-Standard entspricht, und können die Dateiverzeichnisadresse erhalten, die dem PSR0-Standard entspricht Nach dem PSR0-Standard läuft alles reibungslos. Wir können den Namespace verwenden.
 
Als nächstes werfen wir einen detaillierten Blick darauf, was der PSR0-Standard spezifiziert.
 
Nehmen wir einen der Namespaces /Symfony/Core/Request, eine der Drittanbieter-Bibliotheken Symfony in Laravel, als Beispiel, um über den oben genannten PSR0-Standard zu sprechen.
   

1. Ein vollständig qualifizierter Namespace und eine Klasse müssen der Struktur entsprechen: „< Vendor Name>(< Namespace>)* < ;Klassenname>“

/Symfony ist der Name des Anbieters, der der Name der Drittanbieter-Bibliothek ist, und /Core ist der Namespace-Name, im Allgemeinen einige Attributinformationen unseres Namespace (zum Beispiel ist Request die Kernfunktion von Symfony); schließlich ist Request der Name unseres Namespace. Diese Standardspezifikation ermöglicht es den Leuten, die Quelle und Funktion des Namespace sehr klar zu sehen , was der Entwicklung des Codes förderlich ist.
   

2. Jeder Namespace muss einen Top-Level-Namespace („Anbietername“-Anbietername) haben

Das heißt, jeder Namespace muss einen Top-Level-Namespace ähnlich wie /Symfony haben. Warum gibt es eine solche Regel? Da der PSR0-Standard nur für die Zuordnungsbeziehung nach dem Namespace der obersten Ebene verantwortlich ist, wird der Teil von /Symfony/Core/Request, dem das Verzeichnis /Symfony zugeordnet werden soll, vom Benutzer oder vom Framework selbst definiert. Der sogenannte Top-Level-Namespace ist ein Namespace mit benutzerdefinierten Zuordnungsbeziehungen, normalerweise dem Anbieternamen (dem Namen der Drittanbieterbibliothek). Mit anderen Worten: Der Namespace der obersten Ebene ist die Grundlage für das automatische Laden. Warum sind die Standards so festgelegt? Der Grund ist sehr einfach. Wenn es einen Namespace /Symfony/Core/Transport/Request gibt und ein anderer Namespace /Symfony/Core/Transport/Request1 ist, müssen wir zwei Pfade schreiben, wenn es keinen Top-Level-Namespace gibt Was ist, wenn es entsprechend dem Namespace Request2 und Request3 gibt? Für den Top-Level-Namespace /Symfony benötigen wir nur ein entsprechendes Verzeichnis, der Rest kann mit dem PSR-Standard geparst werden.
 

3. Jeder Namespace kann mehrere Unternamespaces haben

Dies kann sehr einfach als /Symfony/Core/Request definiert werden oder Es kann als /Symfony/Core/Transport/Request definiert werden. Unter dem /Core-Namespace können viele Unternamensräume vorhanden sein.

4. Beim Laden aus dem Dateisystem muss das Trennzeichen (/) jedes Namespace in DIRECTORY_SEPARATOR ( OS-Pfadtrennzeichen)

Nun kommen wir endlich zur Mapping-Spezifikation. Das /-Symbol des Namespace muss in ein Pfadtrennzeichen umgewandelt werden, was bedeutet, dass der Namespace /Symfony/Core/Request in eine Verzeichnisstruktur wie SymfonyCoreRequest umgewandelt werden muss.
  

5. Im Klassennamen sollte jeder Unterstrich _ in DIRECTORYSEPARATOR (Betriebssystempfadtrennzeichen) umgewandelt werden. In einem Namensraum hat das Unterstrichsymbol keine (besondere) Bedeutung.

Dieser Satz bedeutet, dass wir, wenn unser Namespace /Symfony/Core/Request_a ist, ihn einem Verzeichnis wie SymfonyCoreRequesta zuordnen sollten. Warum gibt es eine solche Bestimmung? Dies liegt daran, dass es vor PHP5 keinen Namespace gab und Programmierer ihn nur Symfony_Core_Request_a nennen konnten. Diese Bereitstellung von PSR0 soll mit dieser Situation kompatibel sein.
Die restlichen beiden sind sehr einfach und ich werde nicht auf Details eingehen.
  
Mit solchen Namespace-Benennungsregeln und Zuordnungsstandards können wir darüber nachdenken, wo wir die Dateien dort ablegen sollen, wo sich der Namespace befindet. Nehmen wir immer noch Symfony/Core/Request als Beispiel: Das Verzeichnis lautet /path/to/project/vendor/Symfony/Core/Request.php, wobei /path/to/project der Speicherort Ihres Projekts auf der Festplatte ist, /path /to /project/vendor ist das Verzeichnis, in dem sich alle vom Projekt verwendeten Drittanbieterbibliotheken befinden. /path/to/project/vendor/Symfony ist das Verzeichnis, das dem Top-Level-Namespace /Symfony entspricht. Die folgenden Dateiverzeichnisse sind gemäß dem PSR0-Standard eingerichtet:

/Symfony/Core/Request => /Symfony/Core/Request.php

Alles ist perfekt, oder? Nein, es gibt noch einige Mängel:

1. Sollten wir auch ohne Namespaces kompatibel sein?

2. Gemäß dem PSR0-Standard muss der Namespace /A/B/C/D/E/F einer Verzeichnisstruktur /A/B/C entsprechen /D/ E/F, ist diese Verzeichnisstruktur zu tief?

PSR4-Standard

Ende 2013 die fünfte neue Spezifikation - PSR-4.

PSR-4 standardisiert die Angabe eines Dateipfads zum automatischen Laden von Klassendefinitionen und standardisiert außerdem den Speicherort automatisch geladener Dateien. Auf den ersten Blick ähnelt es dem PSR-0. Tatsächlich gibt es einige Überschneidungen in der Funktionalität. Der Unterschied besteht darin, dass die PSR-4-Spezifikation relativ sauber ist, Inhalte entfernt, die mit früheren Versionen von PHP 5.3 kompatibel sind, und sich ein wenig wie eine aktualisierte Version von PSR-0 anfühlt. Natürlich soll PSR-4 PSR-0 nicht vollständig ersetzen, sondern PSR-0 bei Bedarf ergänzen – natürlich kann PSR-4 auch PSR-0 ersetzen, wenn Sie möchten. PSR-4 kann mit anderen automatischen Lademechanismen einschließlich PSR-0 verwendet werden.
 
Der Unterschied zwischen dem PSR4-Standard und dem PSR0-Standard:

1. Die Verwendung von Unterstrichen in Klassennamen hat keine besondere Bedeutung.

2. Die Zuordnungsmethode zwischen Namespace und Dateiverzeichnis wurde angepasst.

Lassen Sie uns den zweiten Punkt im Detail erklären (das Prinzip des automatischen Ladens von Composer):
Angenommen, wir haben einen Namespace: Foo/class , Foo ist der Namespace der obersten Ebene, der eine benutzerdefinierte Zuordnungsbeziehung zum Verzeichnis hat:

<span style="font-size: 14px;">"Foo/" => "src/"<br/></span>

按照PSR0标准，映射后的文件目录是: src/Foo/class.php，但是按照 PSR4 标准，映射后的文件目录就会是:src/class.php，为什么要这么更改呢？原因就是怕命名空间太长导致目录层次太深，使得命名空间和文件目录的映射关系更加灵活。

再举一个例子,来源 PSR-4——新鲜出炉的PHP规范：
PSR-0风格

<span style="font-size: 14px;">    vendor/<br/>    vendor_name/<br/>        package_name/<br/>            src/<br/>                Vendor_Name/<br/>                    Package_Name/<br/>                        ClassName.php       # Vendor_Name\Package_Name\ClassName<br/>            tests/<br/>                Vendor_Name/<br/>                    Package_Name/<br/>                        ClassNameTest.php   # Vendor_Name\Package_Name\ClassName<br/></span>

  PSR-4风格

<span style="font-size: 14px;">    vendor/<br/>    vendor_name/<br/>        package_name/<br/>            src/<br/>                ClassName.php       # Vendor_Name\Package_Name\ClassName<br/>            tests/<br/>                ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest<br/></span>

对比以上两种结构，明显可以看出PSR-4带来更简洁的文件结构。

Das obige ist der detaillierte Inhalt vonPHP implementiert eine automatische Ladefunktion. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!