However, and I don't know if it's because I'm a non native English speaker or if Alan's explanations are using non core classes which are very abstract, but I'm having a hard time understanding how it works and specially when to use it during development.

So let's take this example from the core in app/code/Magento/GoogleAdwords/etc/di.xml:

4 Answers
4

This particular usage is not a good example of using Proxy pattern. I think it is even useless in that particular piece of code, as a collection is not doing any DB operations unless load method is called. If their observer would be used in console command class as the dependency, then it makes sense to use a proxy.

The proxy class should only be used when during construction of the object you execute an expensive operation. A good example is Symfony console commands:

It means on every bin/magento call, no matter which command you execute, the repository dependencies will be instantiated. So the only way to avoid it is to use lazy instantiation of original object by creating a proxy. In this case database, connection to catalog database will be established only when you call a repository method.

The fact that the example I chose is useless got me even more confused. Again theorically I understand the concept. But what I don't get: why would you add ProductRepository as a dependency to the console command if you don't use it for every command. Shouldn't it be a dependency only for the commands you use ? According to what you said, Proxy is a way to "skip" a dependency ? But in that case, why is that a dependency in the first place ?
– Raphael at Digital PianismOct 28 '16 at 7:14

1

I think Symfony console command is a great example, as you must talk to Magento from it, and the only way to do so is to specify a dependency in the constructor. In Symfony console component you must create a class for every single command. This class has configure and execute methods. Configure sets its name and arguments, while execute is actually executing expensive operation. If expensive operation is executed on configure, than you are screwed, that is why proxy is the answer to this problem.
– Ivan ChepurnyiOct 28 '16 at 8:23

A proxy class lets you dependency-inject a class that you won't necessarily need, and that has a high cost associated with doing so.

If you look at a proxy Magento has generated, like \Magento\Framework\View\Layout\Proxy, you'll see it has all of the same methods as the original class. The difference is that every time any of those are called, it checks if the class it's a proxy of has actually been instantiated, and creates the object if not. (This happens in a _getSubject() or _getCache() method.)

It's lazy loading for dependency injection.

You should use a proxy if a class dependency is not always used by your class, and:

Has a lot of dependencies of its own, or

Its constructor involves resource-intensive code, or

Injecting it has side effects

One good example of this is sessions. Getting sessions through the ObjectManager is bad practice, but injecting a session class like \Magento\Customer\Model\Session could break things if your class ever runs outside of that session's scope (say you inject the frontend customer session on an admin page). You get around that by injecting the session's proxy \Magento\Customer\Model\Session\Proxy instead, and only referencing it when you know it's valid. Unless you reference it, the session is never instantiated, and nothing breaks.

In your specific example of di.xml, it looks like they used the proxy to justify injecting a controller rather than that controller's factory. Either way, that is not what proxies are intended to be used for, and the benefit of it in that situation is likely minimal.

Magento 2 type autogenerated proxies can be used to "fix" design mistakes. That can be very handy. There are 2 use cases:

Wrap an expensive object graph that might not be needed every time by the dependee.

Break a cyclic dependency where class A depends on B and class B depends an A.
Injecting B\Proxy into A lets you instantiate A, which then in turn can be used to instantiate B when it is actually used with the real A object.

In case of 1. the dependency that isn't always used is a sign that the dependee class does to much, or maybe does to much by one method. The console command @ivan mentioned are a good example of that.

In case of 2. I don't know a generic way to break up that dependency. I tend to rewrite if there is time, but that might not be an option.

Just as a side note, I would like to add that there are many more types of proxies in OOP than the autogenerated lazy instantiation one Magento 2 uses (e.g. remote proxy).

If you take a close look below code which is written for class "SetConversionValueObserver", if Google adwards is not active "return" and if there is no order "return". Means, Order Collection Object will be created only when order Ids exist and Google adwords active. if we inject actual Order collection class then object manager create collection object with its parent class objects without knowing Google adwords not active and that slow down order success page. so, better create object on demand that is the use of proxy.
/vendor/magento/module-google-adwords/Observer/SetConversionValueObserver.php

when, in general, should one use a proxy class ?
- Inject Proxy class when you feel object creation will be expensive and
class’s constructor is particularly resource-intensive.
- when you don't want unnecessary performance impact due to object creation.
- when you feel object creation should happen when you call particular method in particular condition not always.
For example Layout constructor is a resource-intensive.