[FEAT] Introduce Dependency Injection (DI)

[kasper-agg]

Is there an existing issue for this?

• I have searched the existing issues

Description

Challenge:

The level of inheritance chains makes applying custom changes to any of these classes quite a challenge.
Any of its parent classes needs to be rewritten (<rewrite>) in order to extend the rewritten (Pseudo) Abstract Class.

Example abstract class:
abstract class Mage_Sales_Model_Order_Pdf_Abstract:

class Mage_Core_Model_Session_Abstract extends Mage_Core_Model_Session_Abstract_Varien
{

Example Pseudo Abstract Class:
class Mage_Customer_Model_Address_Abstract

class Mage_Customer_Model_Address_Abstract extends Mage_Core_Model_Abstract
{

In order to change the (pseudo) abstract class, one has three(?) options:

• copy-paste the class and place it in code/local/Mage/, introducing duplicate class names and ambiguous IDE support
• Extend the abstract class by defining a <rewrite> in module/etc/config.xml
• write a composer patch

Proposed feature/solution
Introduce Dependency Injection (DI)

It will allow us to swap out the injected class with our own, while leaving all depending classes unchanged.

Example

final class Mage_Sales_Model_Order_Address implements Mage_Customer_Model_Address_Interface
{

// One can argue that the dependency has to be provided through the actual constructor
    protected function _construct(Mage_Customer_Address_Name_Helper $nameHelper)
    {
        $this->setNameHelper($nameHelper);
        $this->_init('sales/order_address');
    }

  public function getName(): string
  {
    return $this->nameHelper->getName();
  }

Expected Behavior

For the end-user, the behavior of the code remains the same.
Developers however will be able to benefit from all the potential DI has to offer.

Benefits

Beyond what wikipedia has to say about it,
I believe that it will greatly improve code quality, testability and ease of change for core developers, module developers and store owners.

It will help with all the SOLID principles.

It most likely will fix one or two unknown bugs.

Anything else?

I know this is not a light feature request. It basically introduces quite a big framework change.
It is however a change I believe is necessary to truly transform OM and make it a leading Framework.

[EliasKotlyar]

Just to share my perspective on the implementation approach:

I would recommend avoiding a complete reinvention of the wheel. Instead, it may be more pragmatic to leverage Symfony’s Dependency Injection component and introduce a custom attribute for newly added classes—similar to how #[Route] is used in Symfony. This would allow the existing codebase to remain fully backward compatible, while enabling DI where it adds value.

A full-scale refactoring of the entire codebase would likely be a significant undertaking. In contrast, incrementally adding DI support seems much more manageable and lower risk.

As a side note, we previously experimented with running a Symfony kernel inside an OpenMage controller, and it worked reliably without issues. While configuring Symfony’s DI container can feel somewhat complex at first, it becomes straightforward once you are familiar with the setup.

[kasper-agg]

@EliasKotlyar that sounds very interesting. Are you able to share more about your experiment?

Keeping the framework Backward Compatibility was one of my concerns, but it sounds like you already have had it working... :)

[EliasKotlyar]

@kasper-agg i provided a sample "implementation" how i would implement it. It is working, however its just a Proof of Concept. Migrating towards DI needs some decisions from the maintainers.