Irritado com toneladas de classes para DI em construtores de Magento 2 - existe uma maneira melhor?

No momento, estou incomodado de escrever construtores similares em massa, como os seguintes, em meus módulos.

public function __construct(
    \Magento\Framework\Model\Context $context,
    \Magento\Framework\Registry $registry,

    /* ... */

    \Foo\Bar\Model\Baz $baz,

    /* ... */

    \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
    \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
    array $data = []
) {
    $this->registry = $registry;

    /* ... */

    $this->baz = $baz;

    /* ... */

    /* some awesome stuff */
}

Em muitos casos, eu preciso de instâncias das mesmas classes em todo o meu módulo.

Então, eu estava me perguntando se seria uma maneira aceitável de usar uma ou duas classes auxiliares centrais, que fornecem as classes necessárias, em vez de defini-las em cada construtor.

Isso significa um padrão como este:

Classe auxiliar

namespace Foo\Bar\Helper

class Main
{
    protected $baz;



    public function __construct(
        \Magento\Framework\Model\Context $context,
        \Magento\Framework\Registry $registry,

        /* ... */

        \Foo\Bar\Model\Baz $baz,

        /* ... */
    ) {
        $this->registry = $registry;

        /* ... */

        $this->baz = $baz;

        /* ... */

        /* some awesome stuff */
    }



    public function getBazInstance()
    {
        return $this->baz;
    }
}

O construtor mais curto

public function __construct(

    \Foo\Bar\Helper\Main $mainHelper,

    \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
    \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
    array $data = []
) {
    $this->mainHelper = $mainHelper;

    /* some awesome stuff */
}

Neste ponto, não tenho certeza se terei de lidar com grandes desvantagens no futuro causadas por essa estrutura. Seria uma maneira aceitável de reduzir a quantidade de definições de DI?

Confira \Magento\Framework\Model\Context, referenciado em seu exemplo. O que você descreve é ​​exatamente o que faz. Magento usa Contextobjetos semelhantes em todo o núcleo para encurtar listas de DI.

A única coisa a ter em mente é que isso não deve ser usado para ocultar más decisões arquitetônicas . Você deve considerar se cada uma das classes de que você precisa 'em todo o seu módulo' é realmente necessária e, em caso afirmativo, se existe uma maneira alternativa de organizar seu código que atinja melhor o mesmo objetivo. É fácil introduzir problemas de desempenho não intencionais.

Tenho certeza de que você não é o único nesse caso e, de alguma forma, entendo perfeitamente por que você pensou em fazer isso.

Para mim, o principal problema que vejo com essa abordagem é que você perde um dos principais benefícios da Injeção de Dependência, que é saber imediatamente do que sua classe depende ao verificar o construtor.

Outro benefício importante da Injeção de Dependência é que facilita o teste de código em uma estrutura automatizada. No seu caso, essa é definitivamente uma desvantagem.

Essas são as duas razões que surgem, mas pode haver mais.

EDIT: Vou apenas adicionar uma citação de Alan Kent (que faz parte do Magento) que você pode encontrar nos comentários desta pergunta :

Eu geralmente desencorajo a jogar métodos em uma classe auxiliar que não estão relacionados. É melhor ter classes separadas que representam propósitos reais. Ou use métodos estáticos; nesse caso, não há necessidade de um construtor (o código de chamada é responsável por obter identificadores para as estruturas de dados necessárias).