Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Explicitly enable dependency injection for classes with private constructors #3337

Open
mhsdesign opened this issue Mar 28, 2024 · 0 comments

Comments

@mhsdesign
Copy link
Member

Currently Flow allows us to write code like this (inspired by our current ActionRequest):

final class ActionRequest
{
    /**
     * @Flow\Inject
     * @var ObjectManagerInterface
     */
    protected $objectManager;

    /**
     * @Flow\Inject
     * @var PackageManager
     */
    protected $packageManager;

    private function __construct()
    {
    }

    public static function create(): self
    {
        return new self();
    }
    
    // ...
}

Flow will make sure that after instantiating the object from the outside via ActionRequest::create() all dependencies are injected.
This is cool but also rather unexpected from a users perspective. Also it allows for a hacky codestyle while possibly not being aware of it.

Why is this hacky?

Because Flows DI / Proxybuilding goes to great - if not impossible - lengths to archive this. You will likely find no other DI Framework to support this. The code is equivalent to adding this to construct:

private function __construct()
{
    $this->objectManager = \Neos\Flow\Core\Bootstrap::$staticObjectManager;
    $this->packageManager = \Neos\Flow\Core\Bootstrap::$staticObjectManager->get(PackageManager::class);
}

And it will become imminent that this is just super tight coupling which is impossible to unit test.

So i would propose that Flow does not allow Flow\Inject or constructor injection for private constructors but one has to enable this explicitly, possibly by using the existing autowire annotation:

#[Flow\Autowire(true)]
private function __construct()
{
}

Eventually i hope that this will bring more awareness to the crazy parts of Flows DI so that these Features are only used explicitly and we write better more testable and decoupled code at the end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant