クラスのコンストラクターDIでのContext Objectの目的は何ですか？コンテキストの仕組み

クラスのコンストラクタのほとんどでは、Contextオブジェクトが渡されます。このContext Objがどのように機能するか理解できませんでした。また、これは以下のように親クラスのコンストラクターに渡される場合があることに気付きました。

public function __construct(
    \Magento\Framework\App\Action\Context $context,
    \Magento\Catalog\Model\Design $catalogDesign,
    \Magento\Catalog\Model\Session $catalogSession,
....
    parent::__construct(
        $context,
        $layoutFactory,

この特定のコンテキストオブジェクトがどのように機能するか説明してください。

異なるContextオブジェクトがあることに注意してください。この場合、それ\Magento\Framework\App\Action\Contextを理解するには、「ActionContext」と読む必要があります。アクションが実行されるアプリケーションコンテキストを表します。つまり、レジストリアクションやリクエストオブジェクトなど、コントローラーアクションが必要とするアプリケーション状態を持つすべてのオブジェクトにアクセスできます。

コンテキストクラスには独自の機能はなく、他のオブジェクトのコンテナにすぎません。これらは、各コントローラーアクションに20個のパラメーターを持たないショートカットとして表示できます。すべての共通パラメーターは、コンテキストオブジェクトにマージされます。

コンテキストオブジェクトは、抽象クラスのコンストラクターの変更からサードパーティの開発者を隔離するために導入されました。

Magento 1では、多くの「ヘルパー」動作を持つ抽象クラスは、クラスエクステンダーの便利なAPIと見なされていました。抽象クラスのメソッドと暗黙の依存関係のこの生じた膨大な数（AbstractModel、AbstractBlock、AbstractAction）

Magento 2では、継承ベースのAPI（より正確にはSPI）は推奨されていませんが、多くのレガシーAPIがまだ存在しています。最初は、抽象クラスから余分な動作を徐々に削除する予定でした。そして、コンストラクターから依存関係を削除するときにすべてのエクステンダーを壊さないように、Contextオブジェクトを導入しました。

現在の計画では、ある時点で継承ベースのAPIをインターフェースベースのAPIで放棄する予定です。