Introduction
In our previous post, we covered the fundamentals of the Proxy Design Pattern using a simple PHP example. Now let’s look at where this pattern really shines in a real-world platform: Adobe Commerce (Magento 2).
Why Adobe Commerce Needs Proxies
Adobe Commerce makes heavy use of the Proxy pattern through its Object Manager and Dependency Injection (DI) system. Since Magento’s object graph can be very deep — a single class might depend on dozens of other classes, which themselves depend on dozens more — instantiating everything eagerly would hurt performance significantly.
To solve this, Magento auto-generates Proxy classes for you. A proxy class:
- Implements the same interface as the real class.
- Delays instantiation of the real class until one of its methods is actually called.
- Is auto-generated in the
generated/codedirectory — you don’t have to hand-write the boilerplate.
When Are Proxies Useful in Adobe Commerce?
- When a dependency is rarely used but injected into a frequently instantiated class.
- When a dependency triggers a deep or expensive object graph (e.g., loading configuration, connecting to external APIs).
- To resolve circular dependency errors between two interdependent classes.
- To improve page load performance, especially in constructors of classes used across many requests (e.g., Block classes, Plugins, Observers).
What Happens Under the Hood
When you tell Magento to inject a Proxy version of a class instead of the real one, Magento generates a wrapper class that:
- Accepts the Object Manager and the real class name in its constructor.
- Does not instantiate the real class right away.
- Only calls
_getSubject()(which creates the real object) the first time one of its methods is actually called. - Forwards every method call transparently to the real object once it’s created.
This means your consuming class doesn’t need to know or care whether it received the real object or a proxy — both honor the same interface, so the behavior is identical from the caller’s perspective. The only difference is when the expensive object gets created.
The Performance Impact
Without proxies, every request to a Magento storefront page could potentially instantiate hundreds of objects — even ones whose methods are never called during that particular request. By deferring instantiation:
- Constructors become cheap and fast, even for classes with many dependencies.
- Unused dependencies never get built at all in a given request.
- Circular dependencies (Class A needs Class B, which needs Class A) become resolvable, since the proxy breaks the immediate instantiation loop.
Conclusion
Adobe Commerce’s use of the Proxy pattern is a great example of how a classic design pattern solves a very real, very practical performance problem in a large-scale application. In the next post, we’ll walk through the exact steps to create and use a Proxy class in your own Adobe Commerce module.
