I am just trying things out, and I wanted to share an open question that I still have: In a *Factory

Chemaclass

I am just trying things out, and I wanted to share an open question that I still have:
In a Factory, instead using the getProvidedDependency(...) to get the Facade of another Module, if I instantiate the Facade it seems to work just fine 🤔

For example:
Instead of doing this return $this->getProvidedDependency(AnyDependencyProvider::FACADE_STORE); ✔
You could do this return new StoreFacade(); ✔⁉

I would assume the benefits of using the getProvidedDependency(...) is about some internal caching, due to you are not creating a new instance of the same Facade every time, but I would like to verify this assumption, and also I am really curious about if there is any other internal benefits or it’s just pure part of the design itself. Thanks for helping me to clarify this 🤓

PS: I have the feeling that those guys are singleton… but I would like to have a confirmation on this

Chemaclass

I think I can answer myself: yes, the Locator is storing the instances in an internal cache (see static array $instanceCache from ModuleProxy), so we don’t create new instances for those module dependencies 👌

U01LE4BMBK7

especially for connections to the database, Redis, Elasticsearch etc. it's quite important that you use the locator so that it doesn't recreate a connection too often

Chemaclass

yes, exactly! I see it now, it would create too many instances every time you want to “talk” to another module. Having this cache in memory is a really clever solution. Very nice 🤘

U01LE4BMBK7

we had that on a project some years ago and ran into OS limits with tcp connections

UKHD8KTMF

also locator is aware of project level facade extensions

Ahmed Sabaa

Also code bucket extensions and so on, locator is always your friend. It is a 150% requirement on core level, but just on project, as a shortcut, new is fine. It is irrelevant though, there’s no reason to actually skip the provided dependency.

Chemaclass

I have no problems with the locator and the provided dependencies, actually I like it. My “problem” was about understanding the reasons behind this architecture decision. Now it makes sense 😄📚

UQ958DA4U

The major reason for using the DependencyProvider is the same as for any other dependency injection mechanism.

By using this indirection (and an interface), you decouple yourself from the actual implementation. This is how Spryker's module system essentially works. You project namespaces are layered and the top most layer "wins" in dependency resolution. That simply means you can override any module with another on a higher-up layer (e.g. Spryker vs. Pyz layer).
This makes components easy to mock, provides an instance cache (Singletons effectively) and enforces encapsulation and weak typing on an inter-module layer.
This of course assumes that you also use the Locator to get your modules instead of calling them by hand 😉

If you've ever used Java/Kotlin and Spring, you can think of the DependencyProvider and Factory as a split up version fo the Stereotype and Autowiring Annotations (although this comparison only losely holds).

UQ958DA4U

Just an Aside: This mechanism isn't exactly the most modern approach but it enforces module encapsulation so I guess that's why Spryker still uses it. If we look at Laravel for example, a type hint and presence of class (or registered Facade) is enough.

UKHD8KTMF

Spryker avoids magic by design unlike most. Downside is that you have to write a lot of wiring code but that also the benefit, since you are in full control.

UQ958DA4U

I really don't think that Spryker avoids a lot of "magic"; The Locator is "pure magic" by that standard and methods like getFactory() are as well.

UKHD8KTMF

well if you compare this with "modern" auto wiring, auto configuration than there is no magic. Also it is super simple to figure out how the resolver works in Spryker, you just need to look into kernel config getResolvableTypeClassNamePatternMap method where the patterns are defined.

UQ958DA4U

I don't understand why "looking at how it works" (which, in turn, makes the "magic" disappear) is hard on either side but it's totally OK to not agree on every point 😉

UKHD8KTMF

A human readable, non auto generated and debugable code that is explicitly included is by definition not magic. If person does not bothers to look the base class that he is extending and the traits that are included there, well I guess everything is magic.

UKHD8KTMF

So I agree with you @UQ958DA4U, it is in the eye of the beholder 😄