8

At this time I am annoyed of writing similar constructors en masse like the following within my modules.

public function __construct(
    \Magento\Framework\Model\Context $context,
    \Magento\Framework\Registry $registry,

    /* ... */

    \Foo\Bar\Model\Baz $baz,

    /* ... */

    \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
    \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
    array $data = []
) {
    $this->registry = $registry;

    /* ... */

    $this->baz = $baz;

    /* ... */

    /* some awesome stuff */
}

In many many many cases I need instances of the same classes all over my module.

So I was questioning myself, if it would be an acceptable way to use one or two central helper classes, which provide the necessary classes, instead of defining them in every single constructor.

This means a pattern like this:

Helper Class

namespace Foo\Bar\Helper

class Main
{
    protected $baz;



    public function __construct(
        \Magento\Framework\Model\Context $context,
        \Magento\Framework\Registry $registry,

        /* ... */

        \Foo\Bar\Model\Baz $baz,

        /* ... */
    ) {
        $this->registry = $registry;

        /* ... */

        $this->baz = $baz;

        /* ... */

        /* some awesome stuff */
    }



    public function getBazInstance()
    {
        return $this->baz;
    }
}

The shorter constructor

public function __construct(

    \Foo\Bar\Helper\Main $mainHelper,

    \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
    \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
    array $data = []
) {
    $this->mainHelper = $mainHelper;

    /* some awesome stuff */
}

At this point I am not sure if I will have to deal with big disadvantages in future caused by this structure. Would this be an acceptable way to reduce the amount of DI definitions?

7

Check out \Magento\Framework\Model\Context, referenced in your example. What you describe is exactly what it does. Magento uses similar Context objects throughout the core to shorten DI lists.

The only thing to keep in mind is that this should not be used to hide away bad architectural decisions. You should consider whether each of the classes you need 'all over your module' is really necessary, and if so, whether there's an alternate way of organizing your code that would accomplish the same goal better. It's easy to introduce unintentional performance issues.

  • well yes... it sould not be used to "hide away bad architectural decisions" my biggest point is the amount of helpers I have to use (my own and core helpers) the Context classes seemed to me to do exactly what you said, I was just not sure. thx 4 advice – bukart Sep 1 '16 at 6:47
  • So in layman terms, Context Classes are Magento classes that encompass entire sections of Magento? i.e. Category Context, will help manage Add/Edit/Remove/View of Categories without the need of importing multiple classes to do the same action? – MackieeE Apr 10 '17 at 9:06
  • @MackieeE No, not quite. They encompass some of Magento's dependencies for the given class that you're looking at. They're usually rather abstract/far up the inheritance chain, not specific to a particular end class (like Category). If you look at \Magento\Catalog\Model\Category, you'll see that it is including the same \Magento\Framework\Model\Context I mentioned--there's actually nothing in there about categories at all. You're looking for a repository--take a look at \Magento\Catalog\Api\CategoryRepositoryInterface. – Ryan Hoerr Apr 10 '17 at 12:56
4

I'm pretty sure you're not the only one in this case and in some way I totally understand why you thought about doing this.

To me, the main issue I see with such approach is that you lose one of the main benefits of Dependency Injection which is to know straight away what your class depends on when checking the constructor.

Another important benefit of Dependency Injection is that it makes code easier to test in an automated framework. In your case that's definitely one downside.

Those are the two reasons that come up but there may be more.

EDIT: I'm just gonna to add a quote from Alan Kent (who is part of Magento) that you can find in the comments of this question:

I generally discourage throwing methods into a helper class which are not related. It is better to have separate classes that represent real purposes. Or use static methods in which case there is no need for a constructor (the calling code is responsible to get handles to needed data structures).

  • Whereas I wholeheartedly agree on the reasons above. However as a Magento newbie myself - it seems there's a large learning curve to learn which classes are required and dependant on each other before you can begin developing. – MackieeE Apr 10 '17 at 9:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.