Das Problem in einer Zeile

Es gibt eine Zeile Code in Magento-Projekten, die sofort ein Code-Review auslösen sollte:

$service = \Magento\Framework\App\ObjectManager::getInstance()->get(SomeService::class);

Diese eine Zeile ist das Service Locator Pattern – und sie ist in fast allen modernen PHP-Projekten ein Anti-Pattern. Magento dokumentiert es explizit als verboten für eigenen Code. Trotzdem findet man es regelmäßig in Third-Party-Modulen, älterem Code und Stack-Overflow-Antworten.

Dieser Deep Dive erklärt: Was das Service Locator Pattern ist, warum der ObjectManager das klassische Beispiel dafür ist, welche konkreten Probleme es verursacht und wie Constructor Injection es vollständig ersetzt.

1. Was ist das Service Locator Pattern?

Das Service Locator Pattern beschreibt einen zentralen Registry, bei dem sich Code seine Abhängigkeiten aktiv selbst holt statt sie injiziert zu bekommen. Es ist das genaue Gegenteil von Dependency Injection:

Dependency Injection (korrekt):
  Container → inject → Service
  Abhängigkeit wird von außen gegeben
  Klasse deklariert ihre Anforderungen

Service Locator (Anti-Pattern):
  Service → locate → Container → return Dependency
  Klasse holt sich selbst was sie braucht
  Abhängigkeiten sind versteckt

Analogie:
  DI = Restaurant bringt das Essen zum Tisch
  Service Locator = Gast geht selbst in die Küche und sucht das Essen

Das Pattern wurde von Martin Fowler als "Service Locator vs. Dependency Injection" beschrieben. Fowler betont: Beide lösen das Problem der Abhängigkeitsverwaltung, aber Service Locator versteckt die Abhängigkeiten.

2. ObjectManager: Magentos Service Locator

Magentos ObjectManager ist ein vollständiger DI-Container. Als solcher ist er notwendig und legitim – er wird intern vom Framework genutzt, um alle DI-Abhängigkeiten aufzulösen. Das Problem entsteht, wenn Code den ObjectManager direkt aufruft:

<?php
// Das ObjectManager-Interface ist bewusst minimal:
interface ObjectManagerInterface
{
    public function get(string $type): object;    // Shared Object (Singleton-Pool)
    public function create(string $type, array $arguments = []): object; // New Instance
}

// Direkter Aufruf = Service Locator Anti-Pattern:
$om = \Magento\Framework\App\ObjectManager::getInstance();

// Alle folgenden Aufrufe sind Anti-Patterns:
$config     = $om->get(\Magento\Framework\App\Config\ScopeConfigInterface::class);
$product    = $om->create(\Magento\Catalog\Model\Product::class);
$repository = $om->get(\Magento\Catalog\Api\ProductRepositoryInterface::class);

// Warum? Weil die Klasse, die das tut, nicht mehr aus ihrem
// Constructor-Signature erkennbar macht was sie braucht.

<?php
// Beispiel: Service der wie eine Black Box aussieht
class OrderProcessor
{
    // Kein Constructor — keine sichtbaren Abhängigkeiten!
    public function processOrder(int $orderId): bool
    {
        $om = \Magento\Framework\App\ObjectManager::getInstance();

        // Diese Abhängigkeiten sind für den Aufrufer UNSICHTBAR:
        $order       = $om->get(OrderRepositoryInterface::class)->get($orderId);
        $emailSender = $om->get(OrderSender::class);
        $logger      = $om->get(LoggerInterface::class);
        $config      = $om->get(ScopeConfigInterface::class);
        $event       = $om->get(ManagerInterface::class);

        // ... Processing-Code
        return true;
    }
}

// Aufrufer von OrderProcessor weiß nicht:
// - Was OrderProcessor benötigt
// - Was es seiteneffektmäßig tut
// - Wie man es mocken kann

3. Problem 1: Versteckte Abhängigkeiten

Das schwerwiegendste Problem: Klassen, die Service Locator nutzen, haben versteckte Abhängigkeiten. Kein Code-Review, kein IDE und kein statisches Analyse-Tool kann erkennen, was die Klasse wirklich benötigt:

<?php
// Mit Service Locator: Was benötigt diese Klasse?
class InventoryChecker
{
    public function isInStock(int $productId): bool
    {
        // Irgendwo tief im Code...
        $stockItem = \Magento\Framework\App\ObjectManager::getInstance()
            ->get(\Magento\CatalogInventory\Api\StockRegistryInterface::class)
            ->getStockItem($productId);

        return $stockItem->getIsInStock();
    }
}
// Antwort: Weiß man nicht ohne den kompletten Methodenrumpf zu lesen.
// In größeren Klassen: unmöglich ohne vollständige Code-Analyse.

// Mit Constructor Injection: Sofortige Klarheit
class InventoryChecker
{
    public function __construct(
        private readonly \Magento\CatalogInventory\Api\StockRegistryInterface $stockRegistry
    ) {}
    // ↑ Sichtbar: Diese Klasse braucht StockRegistry. Das ist alles.

    public function isInStock(int $productId): bool
    {
        return $this->stockRegistry->getStockItem($productId)->getIsInStock();
    }
}
// Abhängigkeit im Constructor → sichtbar, dokumentiert, erzwungen.

4. Problem 2: Nicht testbar

Das ist der praktisch schwerwiegendste Nachteil. Code mit ObjectManager-Direktzugriffen lässt sich ohne Magento-Bootstrap nicht testen:

<?php
// Service Locator: PHPUnit-Test ist unmöglich ohne Bootstrap
class InventoryCheckerTest extends \PHPUnit\Framework\TestCase
{
    public function testIsInStock(): void
    {
        $checker = new InventoryChecker();

        // PROBLEM: InventoryChecker ruft ObjectManager::getInstance() auf
        // ObjectManager ist in diesem Kontext nicht initialisiert
        // → Fatal Error: ObjectManager not initialized
        // → Nur lösbar durch vollständigen Magento-Bootstrap (langsam, komplex)

        $result = $checker->isInStock(42);
        $this->assertTrue($result);
    }
}

// Constructor Injection: Test funktioniert sofort
class InventoryCheckerTest extends \PHPUnit\Framework\TestCase
{
    public function testIsInStock(): void
    {
        $stockItem = $this->createMock(\Magento\CatalogInventory\Api\Data\StockItemInterface::class);
        $stockItem->method('getIsInStock')->willReturn(true);

        $stockRegistry = $this->createMock(\Magento\CatalogInventory\Api\StockRegistryInterface::class);
        $stockRegistry->method('getStockItem')->with(42)->willReturn($stockItem);

        $checker = new InventoryChecker($stockRegistry); // Mock injizieren!
        $this->assertTrue($checker->isInStock(42));
    }
}
// Kein Bootstrap. Keine Datenbank. Keine Magento-Installation.
// Test läuft in Millisekunden.

5. Problem 3: Keine statische Analyse

<?php
// Service Locator: PHPStan/Psalm kann Abhängigkeiten nicht analysieren
class BadService
{
    public function doSomething(): void
    {
        $repo = ObjectManager::getInstance()->get('Mironsoft\Blog\Api\PostRepositoryInterface');
        // PHPStan: Rückgabetyp ist 'object' — kein Typ-Checking möglich
        // $repo->getById() → PHPStan weiß nicht ob Methode existiert!
        $post = $repo->getById(1);
    }
}

// Constructor Injection: PHPStan analysiert vollständig
class GoodService
{
    public function __construct(
        private readonly PostRepositoryInterface $postRepository // Typ bekannt!
    ) {}

    public function doSomething(): void
    {
        $post = $this->postRepository->getById(1);
        // PHPStan: Methode existiert ✓, Rückgabetyp ist PostInterface ✓
        // Typo in Methodenname? PHPStan meldet es sofort.
    }
}

// PHPStan Regel für Magento (phpstan-magento):
// Meldet ObjectManager::getInstance()-Aufrufe automatisch als Fehler.

6. Problem 4: Sicherheitsrisiken

Service Locator kann in Kombination mit dynamischen Klassen-Namen zu Sicherheitsproblemen führen:

<?php
// GEFÄHRLICH: Dynamische Klassen-Namen aus User Input
class DangerousFactory
{
    public function create(string $type): object
    {
        // type kommt aus User-Input oder einer Datenbank!
        return \Magento\Framework\App\ObjectManager::getInstance()->get($type);
        // Angreifer könnte beliebige Klassen instanziieren
        // → Potential Remote Code Execution wenn Klassen mit Seiteneffekten
    }
}

// Constructor Injection + Allowlist: kein solches Risiko
class SafeFactory
{
    private const ALLOWED_TYPES = [
        'product' => ProductModel::class,
        'order'   => OrderModel::class,
    ];

    public function __construct(
        private readonly ProductFactory $productFactory,
        private readonly OrderFactory $orderFactory
    ) {}

    public function create(string $type): mixed
    {
        return match ($type) {
            'product' => $this->productFactory->create(),
            'order'   => $this->orderFactory->create(),
            default   => throw new \InvalidArgumentException('Unknown type: ' . $type),
        };
    }
}

7. Constructor Injection: Die korrekte Alternative

Constructor Injection ist die vollständige Lösung. Alle Abhängigkeiten werden im Constructor deklariert – der DI-Container löst sie automatisch auf:

<?php
declare(strict_types=1);

namespace Mironsoft\Blog\Model;

use Magento\Framework\App\Config\ScopeConfigInterface;
use Magento\Framework\Event\ManagerInterface as EventManager;
use Mironsoft\Blog\Api\PostRepositoryInterface;
use Psr\Log\LoggerInterface;

/**
 * Order processor with explicit, injectable dependencies.
 * All dependencies visible in constructor — no hidden state.
 */
class PostPublisher
{
    public function __construct(
        private readonly PostRepositoryInterface $postRepository,
        private readonly ScopeConfigInterface $scopeConfig,
        private readonly EventManager $eventManager,
        private readonly LoggerInterface $logger
    ) {
        // Constructor Property Promotion (PHP 8.0+)
        // Alle Abhängigkeiten sind sichtbar, typsicher, mockbar
    }

    /**
     * Publish a blog post.
     * All dependencies explicitly declared — testable without ObjectManager.
     */
    public function publish(int $postId): bool
    {
        try {
            $post = $this->postRepository->getById($postId);
            $post->setStatus(PostInterface::STATUS_PUBLISHED);
            $this->postRepository->save($post);

            $this->eventManager->dispatch('mironsoft_blog_post_published', ['post' => $post]);
            $this->logger->info('Post published', ['id' => $postId]);

            return true;
        } catch (\Exception $e) {
            $this->logger->error('Publish failed', ['id' => $postId, 'error' => $e->getMessage()]);
            return false;
        }
    }
}

8. Erlaubte Ausnahmen: Wann ObjectManager darf

Magento definiert explizite Ausnahmen, in denen ObjectManager-Direktzugriffe erlaubt sind:

Erlaubte ObjectManager-Direktzugriffe:

1. Generierte Factory-Klassen (generated/code/):
   ObjectManager::create() innerhalb von generierten *Factory-Klassen
   → Diese werden von Magento automatisch generiert, nicht manuell geschrieben

2. Proxy-Klassen (generated/code/):
   ObjectManager::get() innerhalb von generierten *Proxy-Klassen
   → Automatisch generiert für Lazy Loading

3. Setup-Scripts (Setup/Patch):
   In InstallData, UpgradeData, DataPatchInterface
   → Constructor hat anderes Interface, kein normales DI verfügbar

4. Test-Bootstrap:
   Integration-Tests Setup (Magento\TestFramework\Helper\Bootstrap)
   → Expliziter Test-Kontext, dokumentiert als Ausnahme

5. pub/index.php und Bootstrap:
   Initialisierung des Containers selbst
   → Notwendiger Bootstrapping-Code

In KEINEM anderen Fall ist ObjectManager::getInstance() erlaubt!

9. Service Locator Anti-Patterns erkennen und fixen

<?php
// Häufige Anti-Patterns und ihre Fixes:

// Anti-Pattern 1: ObjectManager::getInstance()
// Falsch:
$config = \Magento\Framework\App\ObjectManager::getInstance()->get(ScopeConfigInterface::class);
// Richtig:
class MyService {
    public function __construct(private readonly ScopeConfigInterface $scopeConfig) {}
}

// Anti-Pattern 2: ObjectManager als Konstruktor-Dependency
// Falsch:
class BadBlock extends Template {
    public function __construct(
        Context $context,
        private readonly ObjectManagerInterface $objectManager // VERBOTEN!
    ) { parent::__construct($context); }
    public function getService(): MyService {
        return $this->objectManager->get(MyService::class);
    }
}
// Richtig: MyService direkt injizieren

// Anti-Pattern 3: Statische Hilfsmethode mit ObjectManager
// Falsch:
class Helper {
    public static function getConfig(string $path): string {
        return \Magento\Framework\App\ObjectManager::getInstance()
            ->get(ScopeConfigInterface::class)->getValue($path);
    }
}
// Richtig: Helper als Injectable Service mit Constructor Injection

// Anti-Pattern 4: ObjectManager in Event-Observer
// Falsch:
class MyObserver implements ObserverInterface {
    public function execute(Observer $observer): void {
        $product = \Magento\Framework\App\ObjectManager::getInstance()
            ->create(\Magento\Catalog\Model\Product::class);
    }
}
// Richtig: ProductFactory über Constructor injizieren

# Service Locator Anti-Patterns im Code finden:
grep -r "ObjectManager::getInstance" app/code/
grep -r "ObjectManagerInterface" app/code/ | grep -v "use Magento"

# PHPStan mit phpstan-magento Erweiterung:
vendor/bin/phpstan analyse app/code/Mironsoft --level=6
# Meldet ObjectManager-Direktzugriffe automatisch als Fehler

10. Zusammenfassung

Das Service Locator Pattern mit ObjectManager::getInstance() ist das häufigste Anti-Pattern in Magento-Projekten. Es versteckt Abhängigkeiten, macht Code untestbar ohne Magento-Bootstrap, verhindert statische Analyse und kann Sicherheitsrisiken erzeugen. Constructor Injection löst alle diese Probleme – und ist der einzige korrekte Weg für Abhängigkeiten in Magento-Klassen.

11. FAQ: Service Locator Pattern in Magento 2