Good morning, everyone, I try to find out the concept behind the Bridge-classes, e.g. `ProductValidi

U01660GHSTT

Good morning, everyone,
I try to find out the concept behind the Bridge-classes, e.g. ProductValidityToProductFacadeBridgeInterface. I remember something like "Don't use Bridge-classes on project level.". I've heard or read it somewhere. Now I want to understand what the purpose of those classes is and why they shouldn't be used on project level but sadly, I can't find any documentation.

As far as I understand the purpose is to reduce the access to the methods of a facade to a set that is relevant to the current module. But this would mean that it's not possible to not use them on project level.

Does somebody of you know about it or can provide some docs for this?

U01660GHSTT

@UJN2JRU4F this is related to the question of @U01LLUGR1F0 that you were talking about yesterday (if my information is correct 🙂 )

Unknown

bonjour

Unknown

let me check the docs, because there is info for sure.

Unknown

in a nutshell, bridges are the core-side standard adapter implementation for the ModuleToModuleInterfaces you can find in the Dependency/ directory in most Zed modules

Unknown

these abstractions (the interfaces) exist to isolate a module’s business context. nothing in the Business layer directly depends on anything outside the module

Unknown

it’s a bit of module level interface segregation and the second part of dependency inversion

Unknown

docs here 👉 https://documentation.spryker.com/docs/ht-extend-inuse-core

Unknown

i will happily discuss the proposed solution there. and i have my own opinions about it. 🙂

U01LLUGR1F0

Spryker/Zed/ProductValidity/Business/ProductConcrete/ProductConcreteSwitcher.php

/**
 * @param \Spryker\Zed\ProductValidity\Persistence\ProductValidityQueryContainerInterface $queryContainer
 * @param \Spryker\Zed\ProductValidity\Dependency\Facade\ProductValidityToProductFacadeInterface $productFacade
 */
public function __construct(
    ProductValidityQueryContainerInterface $queryContainer,
    ProductValidityToProductFacadeInterface $productFacade
) {
    $this->queryContainer = $queryContainer;
    $this->productFacade = $productFacade;
}

-> here the Bridge is type hinted

We have overwritten the ProductFacade

so we get this in the overwritten Dependency Provider

use ProductFacadeDependencyProviderTrait;

/**
 * @param \Spryker\Zed\Kernel\Container $container
 *
 * @return \Spryker\Zed\Kernel\Container
 */
public function provideBusinessLayerDependencies(Container $container): Container
{
    $container = parent::provideBusinessLayerDependencies($container);

    $this->addProductFacade($container);

    return $container;
}

the used trait overwrites the addProductFacade method like this:

/**
 * @param \Spryker\Zed\Kernel\Container $container
 *
 * @return \Spryker\Zed\Kernel\Container
 */
protected function addProductFacade(Container $container): Container
{
    $container->set(
        ProductDependencyProviderConstants::FACADE_PRODUCT,
        static function (Container $container) {
            /* @phpstan-ignore-next-line */
            return $container->getLocator()->product()->facade();
        }
    );

    return $container;
}

In the parent class it looks like this:

/**
 * @param \Spryker\Zed\Kernel\Container $container
 *
 * @return \Spryker\Zed\Kernel\Container
 */
protected function addProductFacade(Container $container)
{
    $container->set(static::FACADE_PRODUCT, function (Container $container) {
        return new ProductValidityToProductFacadeBridge($container->getLocator()->product()->facade());
    });

    return $container;
}

so therefore we had to add

ProductValidityToProductFacadeInterface

to over overwritten ProductFacade

also we had to overwrite these functions in our overwritten ProductFacade, because the bridge type hints with int, but the facade doesn't

public function activateProductConcrete($idProductConcrete): void
{
    parent::activateProductConcrete($idProductConcrete);
}

public function deactivateProductConcrete($idProductConcrete): void
{
    parent::deactivateProductConcrete($idProductConcrete);
}

this seems really hacky to us, hence my question yesterday if this is really the right way to do it

U01660GHSTT

I just read the documentation you provided. It basically says that we're doing it the way it is proposed there. (And there is the sentence I remembered: "Bridges are for core-level only.")

U01660GHSTT

Thanks a lot

Unknown

well, yes. roughly 🙂

Unknown

there are actually no type hints for the bridge but the ModuleToModuleInterface

Unknown

is the above trait from core side?

Unknown

the documentation also leaves a bit of room for interpretation, but on first glance your solution looks like what is proposed in the docs

U01660GHSTT

The trait is implemented on project level.