Magento 2のコンストラクターでのDIのクラスのトンに悩まされています-より良い方法はありますか？

現時点では、モジュール内で次のような類似のコンストラクターをまとめて作成することにイライラしています。

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 */
}

多くの場合、多くの場合、モジュール全体で同じクラスのインスタンスが必要です。

したがって、必要なクラスを提供する1つまたは2つの中心的なヘルパークラスをすべてのコンストラクターで定義するのではなく、使用するのが許容できる方法であるかどうか、私は疑問に思っていました。

これは、次のようなパターンを意味します。

ヘルパークラス

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;
    }
}

短いコンストラクター

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 */
}

現時点では、この構造によって引き起こされる大きな欠点に対処する必要があるかどうかはわかりません。これはDI定義の量を減らすための許容できる方法でしょうか？

\Magento\Framework\Model\Contextあなたの例で参照されているをチェックしてください。あなたが説明することはまさにそれがすることです。MagentoはContextコア全体で同様のオブジェクトを使用してDIリストを短縮します。

覚えておくべき唯一のことは、これは悪いアーキテクチャの決定を隠すために使用されるべきではないということです。「モジュール全体」で必要な各クラスが本当に必要かどうか、そして必要な場合は、同じ目標をよりよく達成するコードを編成する別の方法があるかどうかを検討する必要があります。意図しないパフォーマンスの問題が発生するのは簡単です。

この場合はあなただけではないことは間違いありません。何らかの理由で、あなたがこれを考えた理由を完全に理解しています。

私にとって、そのようなアプローチで私が目にする主な問題は、コンストラクターをチェックするときにクラスが何に依存するかをすぐに知ることができる依存性注入の主な利点の1つを失うことです。

依存性注入のもう1つの重要な利点は、自動フレームワークでのコードのテストが容易になることです。あなたの場合、それは間違いなく一つの欠点です。

それらが浮上する2つの理由ですが、それ以上の可能性があります。

編集：私はこの質問のコメントで見つけることができるアランケント（Magentoの一部である）からの引用を追加するつもりです：

通常、関連しないヘルパークラスにメソッドをスローすることはお勧めしません。実際の目的を表す個別のクラスを用意することをお勧めします。または、静的メソッドを使用します。この場合、コンストラクターは必要ありません（呼び出しコードは、必要なデータ構造へのハンドルを取得する必要があります）。