Skip to main content

Magento Fundamentals Part 4: Helper Decomposition

What’s a helper?

According to Wikipedia’s definition“in object-oriented programming, a helper class is used to assist in providing some functionality, which isn’t the main goal of the application or class in which it is used.”

Helpers used to be first-class citizens in Magento 1, which left many tracks into Magento 2 codebase.

That’s the reason why, I guess, a lot of Magento developers kept on implementing their helpers, violating the new Magento 2 guidelines.

Why helpers don’t respect the new Magento 2 guidelines

Since, by definition, a helper is a class with many responsibilities, it doesn’t adhere to the class design principles defined in the Magento technical guidelines.

To be more specific, according to the single responsibility principle“there should never be more than one reason for a class to change”.

In Magento 2, many helpers extend the \Magento\Framework\App\Helper\AbstractHelper base class.

In Magento 2.4.2, this class alone depends on:

  • \Magento\Framework\Module\Manager
  • \Psr\Log\LoggerInterface
  • \Magento\Framework\App\RequestInterface
  • \Magento\Framework\UrlInterface
  • \Magento\Framework\HTTP\Header
  • \Magento\Framework\Event\ManagerInterface
  • \Magento\Framework\HTTP\PhpEnvironment\RemoteAddress
  • \Magento\Framework\Cache\ConfigInterface
  • \Magento\Framework\Url\EncoderInterface
  • \Magento\Framework\Url\DecoderInterface
  • \Magento\Framework\App\Config\ScopeConfigInterface

This is a perfect example of a Swiss Army knife with more than one reason to change.

Finish reading on Bitbull.it.