Vorschläge zur Gestaltung der Verfahrensordnung
So viel ich über objektorientierte Programmierung schreibe – und ein Fan von ihr bin –, ich schreibe nicht viel über die Zeiten, in denen ich mit einer prozeduralen Codebasis arbeite .
Die prozedurale Programmierung ist ein Programmierparadigma, das von der strukturierten Programmierung abgeleitet ist und auf dem Konzept des Prozeduraufrufs basiert. Prozeduren, auch bekannt als Routinen, Subroutinen oder Funktionen, enthalten einfach eine Reihe von auszuführenden Berechnungsschritten.
Manchmal komme ich von den Anforderungen eines Projekts, manchmal von einem Projekt, das ich geerbt habe, oder manchmal wegen etwas anderem.
Ich denke, es ist wichtig, dass wir als Programmierer ein Paradigma nicht so hoch halten, dass wir davor zurückschrecken, mit anderen Arten des Codeschreibens zu arbeiten. Schließlich geht es beim Schreiben von Code im Kern darum, ein Problem zu lösen.
Wie das Problem gelöst wird, kann als zweitrangig betrachtet werden.
Unabhängig davon, wann immer ich mit einer Codebasis arbeite; Wie auch immer, es ist geschrieben, ich versuche immer noch sicherzustellen, dass es in einer Weise organisiert ist, die zusammenhängend, so einfach wie möglich zu befolgen ist und im Laufe der Zeit beibehalten werden kann.
Ich dachte, ich würde teilen, wie ich das Schreiben von WordPress-Plugins mit prozeduraler Programmierung im Vergleich zu objektorientierter Programmierung angehe und wie ich prozeduralen Code organisiere.
Nicht zuletzt gibt Ihnen das vielleicht Anregungen für ein aktuelles oder zukünftiges Projekt.
Verfahrensordnung organisieren
Wenn es um die Arbeit mit prozeduralem Code geht, gibt es ein großes Potenzial, fast alles in eine einzige, monolithische Datei aufzunehmen.
Ich bin nicht dieser Ansatz, weil es schwieriger ist, herauszufinden, wo sich etwas in der Datei befindet (zumindest wenn Sie jemand sind, der gerade in ein Projekt kommt).
Zu diesem Zweck sind dies die Dinge, die ich normalerweise tue.
- Separate Aktionen und Filter. Normalerweise nehme ich alle Aktionen und platziere sie in einer Datei und ich nehme alle Filter und platziere sie in einer anderen Datei. Es ist auch möglich, diese Dateien basierend auf ihren Schwerpunkten weiter in Unterverzeichnisse (wenn nicht auch Namespaces) zu unterteilen. Beispielsweise können alle Aktionen im Zusammenhang mit dem Verwaltungsbereich in einem Admin – Unterverzeichnis abgelegt werden.
- Schreiben Sie eine Debug-Datei. Normalerweise füge ich ein einfaches Debug-Skript in ein Plugin ein, damit ich Debug-Informationen einfach auf dem Bildschirm darstellen, in die Debug-Protokolldatei schreiben oder in beide schreiben kann. Dies mag eine Bequemlichkeit sein, wenn nichts anderes, aber es hilft, eine Möglichkeit zu bieten, leicht zu sehen, was passiert, ohne Xdebug starten und den Code schrittweise durchlaufen zu müssen (es sei denn, es handelt sich um ein komplizierteres Problem).
- Autoloader. Wenn Sie prozeduralen Code verwenden, verwenden Sie möglicherweise überhaupt keine Namespaces, aber wenn ja, füge ich auch einen Autoloader hinzu, den ich geschrieben habe, um das automatische Einschließen von Dateien zu vereinfachen. Dies ist anders als der Autoloader, den Composer generiert, aber es macht immer noch dasselbe.
Offensichtlich gibt es an den obigen Empfehlungen nichts Kompliziertes. Tatsächlich würde ich sagen, dass jeder der oben genannten Punkte, insbesondere der erste Schritt, einen großen Beitrag zur Verbesserung der Verwaltbarkeit von prozeduralem Code leisten kann.
Die Haupt-Plugin-Datei
Wenn Sie sich für alle oben genannten Schritte entscheiden, sollte die endgültige Version der Bootstrap-Datei des Plugins wirklich einfach sein. Tatsächlich kann es so einfach aussehen :
<?php
/**
* Plugin Name: Acme Plugin
* Plugin URI: https://acmeplugins.com/acme
* Description: This is the plugin description.
* Version: 1.0.0
* Author: Acme Plugins Co.
* Author URI: https://acmeplugins.com/acme
* License: GPL-3.0+
* License URI: http://www.gnu.org/licenses/gpl-3.0.txt
*
* @since 1.0.0
* @package Acme
*/
namespace Acme;
defined( 'WPINC') || die;
// Include the custom autoloader.
require_once __DIR__. '/inc/autoload.php';
// Include action and filters.
require_once __DIR__. '/inc/actions.php';
require_once __DIR__. '/inc/filters.php';
Auch dies setzt voraus, dass Sie alle drei Empfehlungen anwenden. Wenn nicht, kann Ihre Implementierung variieren.
