21

In Magento 2, most of classes have these two constructs (__construct and _construct) methods. What is the difference between them?

17

I'm not completely sure if it has changed between Magento 1 and Magento 2, probably not so I'm gonna go with what I know from Magento 1.

The _construct will be called after the __construct

The PHP native __construct method should not be overwritten or used in your code. If you want to execute code in a safe way on the start of a class use _construct.

Magento will use the native __construct to make sure everything is 'ready' for a class to be used such as defining the right cache tags for a certain model for example.

15

The _construct method was a "Varien invention" used to wrap some initialization logic in models, helpers and blocks.

So is unusual to change or re-declare the native __construct() method in M1 Models/Blocks or Helpers since we always use the Magento factories. However isn't any problem/bad-practice about using it (if you care of compatibility).

In M2 the _construct() method still present in some parts and is used for the same purposes, but now (in M2) all DI logic is implemented by the __constructor() so you will find a lot of construct declarations in the code base.

BTW there is no more factories like Mage::getModel() in M2.

In Other words:

The _construct() method is implemented by Magento in some classes and it's called automatically inside the __construct function declaration, so if you are extending a Magento class like a Model you can use it to perform some stuff after object creation.

In a Resource Model or Model Class you should define a _construct() method in order to define the table and the primary_key

In the other hand the __construct is a native method of PHP (All OO languages have one), __construct is called every time you instantiate an object. That's all

Example:

Magento\Framework\Model\ResourceModel\AbstractResource

/**
 * Abstract resource model
 */
abstract class AbstractResource
{
    /**
     * Main constructor
     */
    public function __construct()
    {
        /**
         * Please override this one instead of overriding real __construct constructor
         */
        $this->_construct();
    } ...

Magento\Framework\Model\ResourceModel\Db\AbstractDb

/**
 * Class constructor
 *
 * @param \Magento\Framework\Model\ResourceModel\Db\Context $context
 * @param string $connectionName
 */
public function __construct(\Magento\Framework\Model\ResourceModel\Db\Context $context, $connectionName = null)
{
    $this->transactionManager = $context->getTransactionManager();
    $this->_resources = $context->getResources();
    $this->objectRelationProcessor = $context->getObjectRelationProcessor();
    if ($connectionName !== null) {
        $this->connectionName = $connectionName;
    }
    parent::__construct();
}
  • Can you please provide example ? – zed Blackbeard Dec 28 '15 at 9:54
  • In M2? i can improve the answer in order to make more clear the difference, but i don't know if an example is needed, – MauroNigrele Dec 28 '15 at 9:58
  • I am interested in your opinion on something related to DI and __construct(). Seems that the so called "DI logic" in Magento2 is implemented, as anti-pattern, since it actually creates tight coupling. Running a composer update, dependent on how many 3d party modules you have extended with your modules, can often lead to need to debug, add params in constructors, that are not really used in the child-classes, just to keep the application running. Not sure that it should even be called a "Dependency Injection", but dependency anchoring or something... – someGuyOnTheWeb Jun 13 '18 at 9:19

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.