“Helpers” are often used as convenient collection of functions. They are also a sign of bad design, and I want you to stop writing them. I’ll quote myself

In general, having classes named “Helper”, “Util” or similar just says “I have some functions that I don’t know where to put” and don’t make much sense as a class.

It’s not very object oriented. Not at all to be frank. The idea of object oriented programming is that there are objects that send each others messages. They have an active role in the system and are not just containers for data and code, which would be a very procedural way to see them.

So what would be the role of a helper? A butler maybe, that does not act on its own and will do anything you tell him. But to do that, he needs access to your whole household, your bank account and your car.

In a system like Magento 2 with consequent usage of dependency injection this is even more evident. The more functions you add to a helper, the more dependencies it collects.

Example

I’ll give an example how typical helper functionality can live better in its own class. I recently added a feature to our Magento module IntegerNet_Anonymizer to exclude customers from certain email domains from being anonymized. The domains would come from a configuration value. I needed to check email addresses against these configured value at several places. Now the naive way would be to create a helper method like this in the module helper (in Magento 1.x each module has one default helper class)

public function isEmailExcluded($email) { $excludedDomains = array_map( 'trim', explode(',', Mage::getStoreConfig(self::CONFIG_EXCLUDED_EMAIL_DOMAINS)) ?: [] ); $emailDomain = preg_replace('{.*@(.*)}', '$1', $email); foreach ($excludedDomains as $domain) { if ($emailDomain === $domain) { return true; } } return false; }

What did I do instead? Put this logic in its own class ExcludedEmailDomains, with one method

public function matches($email)

but without the dependency to the Magento configuration. $excludedDomains are passed via constructor instead.

Now this is not a “helper” anymore, this is an actual object with an identity. It represents a list of domains. Within the Magento module this would be a “model”.

Why is this good? Suddenly, it was really easy to unit test the logic (see ExcludedEmailDomainsTest): no dependencies, nothing to be mocked, no Magento involved.

And where I use it, I don’t need to buy a whole mixed lot of unrelated functions. Keep in mind that having many classes is not bad, having classes that do too much on the other hand, is a code smell, a sign of bad design.

If you look at the rest of the module, you’ll notice that I still added a method to the module helper, which acts as factory method. In the post quoted above, in the context of Magento 1.x, I also said:

However, I would not be too strict about “not using helpers at all” and instead use them for query shortcuts like: access module configuration:

factory methods for library classes You could find other places but IMHO, the module helper is often good enough for things like that.

So I actually won’t blame you for writing helpers, but please think before you do and keep them as stupid as possible. If your helpers contain any domain logic, you are doing it wrong.