grep -RInP 'ObjectManager\s*::\s*getInstance\s*\(' app/code

Gefunden werden damit beispielsweise Stellen wie:

$objectManager = \Magento\Framework\App\ObjectManager::getInstance();

$productRepository = $objectManager->get(
    \Magento\Catalog\Api\ProductRepositoryInterface::class
);

Der reguläre Ausdruck berücksichtigt auch unterschiedliche Leerzeichen rund um :: und vor der öffnenden Klammer. Mit -R wird rekursiv gesucht, -n gibt die Zeilennummer aus und -P aktiviert die Perl kompatiblen regulären Ausdrücke von grep.

Auch typische anschließende Aufrufe über eine Variable namens $objectManager lassen sich suchen:

grep -RInP '\$objectManager\s*->\s*(get|create)\s*\(' app/code

Direkte ObjectManager Nutzung gilt im eigenen Magento Code in der Regel als Bad Practice. Der wichtigste Grund ist, dass die tatsächlichen Abhängigkeiten einer Klasse dadurch versteckt werden. Am Konstruktor ist nicht mehr erkennbar, welche Services die Klasse benötigt, weil diese erst irgendwo innerhalb einer Methode aus dem ObjectManager geholt werden.

Das macht den Code schwerer verständlich und vor allem schwerer testbar. Bei sauberer Dependency Injection kann eine benötigte Abhängigkeit in einem Unit Test einfach durch ein Mock Objekt ersetzt werden. Holt sich die Klasse ihren Service dagegen selbst über den globalen ObjectManager, muss der Test zusätzlich diesen versteckten Zugriff berücksichtigen.

Auch z.B. Änderungen werden unnötig schwieriger. Benötigt eine Klasse fünf Services über den Konstruktor, ist dies sofort sichtbar. Werden dieselben fünf Services über verschiedene Methoden verteilt aus dem ObjectManager geladen, erkennt man diese Abhängigkeiten erst beim Lesen des gesamten Codes.

Sauberer ist deshalb die direkte Übergabe über den Konstruktor:

use Magento\Catalog\Api\ProductRepositoryInterface;

public function __construct(
    private ProductRepositoryInterface $productRepository
) {
}

Magento kann die konkrete Implementierung anschließend selbst über seine Dependency Injection Konfiguration auflösen. Preferences, Proxies, Plugins und andere Mechanismen des Object Managers funktionieren dabei weiterhin, nur die Klasse selbst muss nicht wissen, wie ihre Abhängigkeit erzeugt wird.

Der ObjectManager ist also nicht grundsätzlich etwas Schlechtes, Magento selbst basiert schließlich darauf. Problematisch ist normalerweise der direkte Zugriff aus dem eigenen Anwendungscode, weil damit aus Dependency Injection praktisch ein versteckter Service Locator wird.