Qual é o objetivo do objeto de contexto no construtor de qualquer classe DI? Como o contexto funciona?

Na maioria dos construtores da classe, um objeto Context é passado. Eu não conseguia entender como esse Obj de contexto funciona. Também notei que algumas vezes isso é passado para o construtor da classe pai, como abaixo.

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

Você pode explicar como esse objeto de contexto específico funciona?

Observe que existem diferentes objetos de contexto, neste caso é \Magento\Framework\App\Action\Context e para entendê-lo, você deve lê-lo como "ActionContext". Representa o contexto do aplicativo no qual a ação é executada. Em outras palavras, ele fornece acesso a todos os objetos com o estado do aplicativo que uma ação do controlador precisa, por exemplo, o registro ou o objeto de solicitação.

As classes de contexto não possuem funcionalidade própria, são apenas um contêiner para outros objetos. Você pode vê-los como atalho para não ter 20 parâmetros em cada ação do controlador. Todos os parâmetros comuns são mesclados no objeto de contexto.

Objetos de contexto foram introduzidos para isolar desenvolvedores de terceiros de alterações nos construtores de classes abstratas.

No Magento 1, as classes abstratas com muito comportamento "auxiliar" foram consideradas uma API conveniente para o extensor de classes. Isso causou um grande número de métodos e dependências implícitas em classes abstratas ( AbstractModel, AbstractBlock,AbstractAction )

No Magento 2, APIs baseadas em herança (mais precisamente SPIs) são desencorajadas, mas ainda existem muitas APIs herdadas. Inicialmente, planejamos remover gradualmente o comportamento extra das classes abstratas. E para não quebrar todos os extensores quando removeríamos alguma dependência do construtor, introduzimos objetos Context.

O plano atual é abandonar APIs baseadas em herança com APIs baseadas em interface em algum momento.