Objektorientierung, Namespaces und Composer

Kleine Anpassungen lassen sich gut mit einzelnen Funktionen schreiben. Sobald ein Plugin wächst – mit eigenen Inhaltstypen, Einstellungen, Schnittstellen und Hintergrundaufgaben –, wird eine Sammlung loser Funktionen schnell unübersichtlich. Objektorientierte Programmierung hilft, Code in sinnvolle Einheiten zu gliedern: Klassen, die zusammengehörige Daten und Funktionen bündeln. Moderne WordPress-Plugins nutzen dazu Namespaces, um Konflikte mit anderen Plugins zu vermeiden, und Composer, um Abhängigkeiten zu verwalten und Klassen automatisch zu laden. Diese Lektion zeigt die Grundlagen – genug, um moderne Plugins zu lesen und eigene sauber aufzubauen.

1. Klassen und Objekte

1<?php
2class Kurs {
3    public function __construct(
4        public readonly string $titel,
5        private int $plaetze,
6    ) {}
7
8    public function buchen(): bool {
9        if ( $this->plaetze === 0 ) {
10            return false;
11        }
12        $this->plaetze--;
13        return true;
14    }
15}
16
17$yoga = new Kurs( 'Yoga am Morgen', 1 );
18echo $yoga->buchen() ? 'gebucht' : 'voll';
19echo ' / ';
20echo $yoga->buchen() ? 'gebucht' : 'voll';

Die Sichtbarkeit steuert, wer auf Eigenschaften und Methoden zugreifen darf. public ist von überall erreichbar, private nur innerhalb der Klasse, protected zusätzlich in abgeleiteten Klassen. So wird verhindert, dass anderer Code die Plätze direkt verändert – das geht nur über die Methode buchen(), die dabei die Regeln einhält.

2. Namespaces

Wie bei Funktionen dürfen auch Klassennamen in WordPress nicht mit anderen Plugins kollidieren. Namespaces lösen das elegant: Sie sind wie Ordner für Code. Die Klasse Kurs im Namespace Studio\Buchung heißt vollständig Studio\Buchung\Kurs und kollidiert nicht mit einer Klasse Kurs in einem anderen Plugin.

1<?php
2namespace Studio\Buchung;
3
4use WP_Post;   // Klassen aus dem globalen Namensraum importieren
5
6class Kurs {
7    public static function aus_beitrag( WP_Post $beitrag ): self {
8        return new self( $beitrag->post_title, (int) get_post_meta( $beitrag->ID, 'plaetze', true ) );
9    }
10    // …
11}

1<?php
2namespace Studio\Buchung;
3
4function hallo(): string { return 'Studio'; }
5
6echo \Studio\Buchung\hallo() . ' ' . hallo();

3. Composer

Ohne Composer müsste jede Klassendatei mit require eingebunden werden. Mit Composer genügt eine Zeile im Haupt-Plugin, und alle Klassen im Ordner src werden bei Bedarf geladen – vorausgesetzt, Ordner und Dateinamen folgen dem Namespace. Diese Konvention heißt PSR-4. Zusätzlich kann Composer fremde Bibliotheken einbinden, etwa für PDF-Erzeugung oder HTTP-Anfragen. Klicken Sie sich durch die Einrichtung:

1{
2  "name": "studio/buchung",
3  "require": { "php": ">=8.1" },
4  "autoload": {
5    "psr-4": { "Studio\\Buchung\\": "src/" }
6  }
7}

4. Moderne PHP-Merkmale

5. Wann Objektorientierung, wann nicht?

Nicht jedes Stück Code braucht Klassen. Für ein kleines Plugin mit zwei Hooks sind einfache, gut benannte Funktionen völlig in Ordnung. Klassen lohnen sich, wenn Daten und Verhalten eng zusammengehören – etwa ein Kurs mit Plätzen und Buchungslogik –, wenn mehrere Teile eines Plugins dieselben Abhängigkeiten nutzen oder wenn Code getestet werden soll. Ein häufiger Fehler ist, alles in eine riesige Klasse mit dutzenden Methoden zu packen. Besser sind mehrere kleine Klassen mit klaren Aufgaben: eine für den Inhaltstyp, eine für die Einstellungen, eine für die REST-Schnittstelle.

6. Ein Beispiel

Ein Yogastudio ließ sich ein Buchungs-Plugin entwickeln. Anfangs bestand es aus einer Datei mit vierzig Funktionen; jede Änderung war riskant, weil niemand den Überblick hatte. Beim Umbau entstanden ein Namespace Studio\Buchung, Klassen für Kurs, Buchung, Warteliste, Einstellungen und REST-Schnittstelle sowie ein Composer-Autoloader. Die Buchungslogik steckt nun in der Klasse Kurs mit der Methode buchen(), die immer dieselben Regeln einhält – egal ob über die Website, die REST API oder später einen KI-Agenten gebucht wird. Neue Funktionen wie eine Warteliste ließen sich seitdem in einer eigenen Klasse ergänzen, ohne den übrigen Code anzufassen.

7. Häufige Fragen

Muss ich Composer auf dem Server installieren? Nicht unbedingt. Composer wird meist auf dem Entwicklungsrechner ausgeführt, und der erzeugte Ordner vendor wird mit dem Plugin ausgeliefert. Wichtig ist, nur die für den Betrieb nötigen Pakete mitzuliefern und Entwicklungswerkzeuge auszuschließen, etwa mit composer install --no-dev.

Was passiert, wenn zwei Plugins dieselbe Bibliothek in verschiedenen Versionen mitbringen? Das ist ein bekanntes Problem in WordPress, weil alle Plugins im selben PHP-Prozess laufen. Es kann zu schwer auffindbaren Fehlern führen. Größere Plugins lösen es, indem sie die Namespaces ihrer Abhängigkeiten mit Werkzeugen wie PHP-Scoper umschreiben. Für kleine Plugins gilt: so wenige Fremdbibliotheken wie möglich.

Nutzt WordPress selbst Objektorientierung? Ja, zunehmend. Klassen wie WP_Query, WP_Post, WP_REST_Controller oder die Abilities API sind objektorientiert. Viele ältere Teile sind noch funktional aufgebaut, weil WordPress großen Wert auf Rückwärtskompatibilität legt. Für eigene Plugins ist ein moderner, objektorientierter Aufbau heute der Standard.

8. Übung zum Selbermachen

Wandeln Sie die Funktion aus der vorigen Übung in eine Klasse um. Legen Sie in WordPress Playground einen Namespace Uebung an, eine Klasse Kurs mit Titel, Plätzen und Preis als Eigenschaften über Konstruktor-Promotion und eine Methode istAusgebucht(). Eine zweite Klasse Kursliste nimmt mehrere Kurse entgegen und hat eine Methode alsHtml(). Überlegen Sie, welche Eigenschaften öffentlich sein sollen und welche besser privat bleiben. Wer Composer lokal installiert hat, kann das Ganze als kleines Plugin mit composer.json und Autoloader aufbauen – genau so, wie es Modul 4 für echte Plugins zeigt. Der Vergleich mit der funktionalen Fassung macht deutlich, wann Objektorientierung Klarheit bringt und wann sie für kleine Aufgaben zu viel ist.

Stand: September 2026, WordPress 7.1, PHP 8.3. Kursmaterial der Klarwerk Akademie. WordPress entwickelt sich schnell – maßgeblich ist die aktuelle Dokumentation auf developer.wordpress.org.