What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

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

Chemaclass
Chemaclass Tech Lead Spryker Solution Partner Posts: 213 πŸ§‘πŸ»β€πŸš€ - Cadet
edited March 2021 in Slack General

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

Comments

  • Chemaclass
    Chemaclass Tech Lead Spryker Solution Partner Posts: 213 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    U01LE4BMBK7 Posts: 241 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    Chemaclass Tech Lead Spryker Solution Partner Posts: 213 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    U01LE4BMBK7 Posts: 241 πŸ§‘πŸ»β€πŸš€ - Cadet

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

  • UKHD8KTMF
    UKHD8KTMF Posts: 393 πŸ§‘πŸ»β€πŸš€ - Cadet

    also locator is aware of project level facade extensions

  • Ahmed Sabaa
    Ahmed Sabaa Senior Application Architect @Spryker Sprykee Posts: 54 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    Chemaclass Tech Lead Spryker Solution Partner Posts: 213 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UQ958DA4U Posts: 232 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UQ958DA4U Posts: 232 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UKHD8KTMF Posts: 393 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UQ958DA4U Posts: 232 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UKHD8KTMF Posts: 393 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UQ958DA4U Posts: 232 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UKHD8KTMF Posts: 393 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UKHD8KTMF Posts: 393 πŸ§‘πŸ»β€πŸš€ - Cadet

    So I agree with you @UQ958DA4U, it is in the eye of the beholder πŸ˜„