Understanding The 13 Design Patterns In Magento 2

• How Does Design Pattern In Magento 2 Work?

• What Is Service Contract Design Pattern In Magento 2?

• Types Of Design Patterns In Magento

• What Is Object Manager In Magento?

• What Are Injectable And Non-Injectable Objects In Magento 2?

• What Is Magento 2 Dependency Injection?

• FAQs

• Summary

How Does Design Pattern In Magento 2 Work?

Classes that inherit from Mage_Core_Model_Abstract have access to load(), save(), and delete() methods. They allow them to load, modify, create, or delete records in a connected database table. Additionally, Mage_Core_Model_Abstract inherits from Varien_Object. It provides access to the __set() and __get() methods. It automatically maps database table columns to the object's properties. The view section in Magento is divided into three parts:

• Layout (an XML file defining what and where to display on a page)
• Template (a PHTML file responsible for how an item is displayed)
• Block (which retrieves data from the model and passes it to the template)

What Is Service Contract Design Pattern In Magento 2?

Magento is a modular or extension-based system. It allows third-party developers to customize and overwrite core parts of its framework. However, these customizations can lead to issues. It can lead to difficulty in tracking changes made by external extensions.

To address this, Magento uses the Service Contract pattern. A service contract is a set of interfaces acting as a layer between the end user and the business layer. It prevents direct exposure of business logic for customization.

Service contracts enhance Magento's modularity. It makes it easier for merchants to upgrade Magento with a well-defined and durable API. Both external and Magento modules can implement them. They provide a direct way to expose business logic via REST or SOAP interfaces. It ensures consistent and maintainable customizations.

By utilizing these contracts, developers can:

• Create more loosely coupled modules by relying on interfaces instead of concrete implementations.
• Easily replace implementations without impacting other parts of the system.
• Ensure backward compatibility, as changes to the implementation do not affect the interface.
• Enhance testability by enabling easy mocking of dependencies.

For instance, consider the ProductRepositoryInterface. Any module that needs to interact with products can rely on this interface instead of a specific implementation. It facilitates easier customization and extension of product-related functionality.

Types Of Design Patterns In Magento

1. Model View Controller

MVC is a design pattern where business, presentation, and coupling logic are separated. Magento utilizes a unique MVC pattern with a DOM-based configuration layer. It leverages XML to drive the configuration and actions of the Magento application. Views in Magento often contain significant logic. They are supported by an additional PHP class (Block system) for rendering. Varien’s ORM backs models. Here, most business logic occurs while controllers map model data to the views.

2. Front Controller Pattern

Magento uses the Front Controller pattern (index.php) to ensure there is a single point of entry for all requests. This entry point initializes the application environment using Mage::app(). It then routes requests to the appropriate controllers for processing. It is responsible for investigating, routing, and processing requests according to specifications. It ensures efficient workflow execution.

3. Factory Pattern

The Factory pattern in Magento is used to instantiate classes uniformly throughout the codebase. It leverages the autoloading system. By defining an alias in a module's config.xml, the factory knows where to find the classes. The getModel() method in the Mage core class, for example, accepts an alias for a class and returns an instance of it. This approach eliminates the need for scattered calls and ensures consistent class instantiation. Class groups and their abstractions are declared in the XML configuration files within the module’s /etc/ folder.

4. Singleton Pattern

To retrieve an instance of a class in Magento, you can use Mage::getSingleton(). This method accepts a class alias. It checks the internal registry to see if the class has already been instantiated. If it has, it returns the shared instance. This is essential for scenarios like session storage that need to be consistent. The Singleton pattern is used for instantiating Blocks and Classes in Magento. It ensures that they are shared and not recreated multiple times.

5. Registry Pattern

The Registry pattern in Magento provides a global scope container for storing data or objects. It makes them publicly available for any resource to use. All singletons are stored in this internal registry. You can use the Mage::register($key, $value), Mage::registry($key), and Mage::unregister($key). These methods store, retrieve, and remove data from the registry, respectively. This pattern is useful for transferring data between scopes when direct passing is not possible.

6. Prototype Pattern

The Prototype pattern in Magento extends the Abstract Factory pattern. It ensures that instances of classes can retrieve specific other class instances based on their parent class (prototype). For example, the Mage_Catalog_Model_Product class uses the getTypeInstance method. It does this to retrieve a specific Mage_Catalog_Model_Product_Type. It has methods and properties not applicable to all products.

A notable instance is the Mage_Downloadable_Model_Product_Type, which extends Mage_Catalog_Model_Product_Type. When iterating over an order and needing a method specific to a downloadable product, the getTypeInstance method ensures the correct class is instantiated. This pattern guarantees a specific class defined by its parent type. The appropriate subclass is provided to handle the requirements.

7. Object Pool Pattern

The Object Pool pattern in Magento retains objects for repeated use. It avoids the need to re-instantiate and destroy them repeatedly. This approach is particularly useful for saving on memory consumption and compute cycles. It occurs especially during heavy tasks like importing products. Managed by Varien_Object_Cache, the object pool can be accessed using Mage::objects(). Although not widely used in Magento, it proves beneficial for resource-intensive operations.

8. Iterator Pattern

The Iterator pattern in Magento provides a consistent way to iterate over a container with objects. This is managed by Varien_Data_Collection. It utilizes various PHP classes like ArrayIterator to offer an object-oriented interface to arrays. This ensures that model collections always have a common API for iteration. This is independent of the actual models. It allows an object to traverse through elements of another class. It facilitates the passing of multiple data sets. It does this without altering the underlying structure that supports iteration.

9. Lazy Loading Pattern

The use of Lazy Loading design pattern delays loading data until it is actually needed. It results in less resource usage. In Magento, this behavior is seen with collections. For example, when retrieving a collection of products using Mage::getModel('catalog/product')->getCollection(), the database is only accessed when the collection is actually used. For example, it happens during iteration or when retrieving the count of models found. While Magento uses Lazy Loading for data rather than objects, it optimizes resource usage. For example, you can:

• Enhance initial page load times by loading only the necessary data upfront.
• Reduce memory usage, which is important for large catalogs or complex product configurations.
• Improve scalability by more efficiently distributing database queries.

For example, when loading a category page, product details are often lazy-loaded as the user scrolls instead of loading all product data at once. This reduces the initial load time and server resource usage.

10. Service Locator Pattern

The Service Locator pattern abstracts the retrieval of a service. It allows changes to the service without breaking functionality. This pattern encapsulates the process within an abstraction layer. It enables users to fetch the appropriate service without needing to know its specifics at runtime. For instance, the caching mechanism uses Mage::getCache() as a service locator by proxy for cache storage. It is supplied by Zend or other vendors. This approach ensures flexibility and adaptability in service management.

11. Module Pattern

Anyone familiar with Magento development has encountered the Module pattern. This design pattern groups different domains into independent modules. These separate modules can be plugged into the main system as needed. Ideally, the Module pattern ensures each element can be removed or swapped. One key example in PHP is the Composer package manager. While Magento relies heavily on a modular architecture, it is not entirely modular. Some functionalities are tightly integrated into the core. This makes them difficult to change. Also, the extensive use of the super-global Mage core-class introduces system-wide dependencies. These are sometimes challenging to manage. It emphasizes modular programming. It groups a program’s functionality into interchangeable modules.

12. Observer Pattern

Magento's event-driven architecture is based on the Observer pattern. It allows the definition of observers (listeners) to execute additional code when an observed event fires. Magento uses its XML data storage to define these observers. When an event is fired using Mage::dispatchEvent($eventName, $data), the system consults the data storage. It then triggers the appropriate observers for the event. This mechanism allows for customizing existing logic without modifying the core code. It places an event listener at specific points during application execution. It enables other components to hook into these events and execute their code.

13. Active Record

Objects in Magento represent a row in a database table. These objects have properties that correspond to the table's columns and methods. They allow modifications of these properties in the database.

What Is Object Manager In Magento?

Magento's Object Manager implements many design patterns. For Example:

• Dependency Injection
• Singleton
• Factory
• Abstract Factory
• Composite
• Strategy
• CQRS
• Decorator

Dependent Objects are responsible for instantiating and configuring objects. Magento prohibits its direct use to maintain proper dependency management.

Objects with a proxy class automatically handle parameters in class constructors. In Magento 1, objects were managed via the Mage class. However, in Magento2, the Object Manager replaces this functionality. It creates a close relationship between object management, dependency injection, and plugins.

Proxy class object uses two main methods: GET and CREATE.

<?php

namespace Magento\Framework;

/**
 * @api
 */
interface ObjectManagerInterface
{
    /**
     * Create a new object instance  
     *  
     * @param string $type  
     * @param array $arguments  
     * @return mixed  
     */  
    public function create($type, array $arguments = []);

    /**  
     * Retrieve cached object instance  
     *  
     * @param string $type  
     * @return mixed  
     */  
    public function get($type);

    /**  
     * Configure object manager  
     *  
     * @param array $configuration  
     * @return void  
     */  
    public function configure(array $configuration);  
}

The GET method returns a singleton object. It shares the same instance across components. The CREATE method generates a new object instance each time it is called. This ensures that if GET is called from two places, the same result is produced. Whereas, CREATE yields a new object each time.

The occurrence of proxy classes in Magento includes:

• Instantiating and injecting classes declared in constructors.
• Implementing the Singleton pattern.
• Managing dependencies.
• Automatically instantiating parameters.

What Are Injectable And Non-Injectable Objects In Magento 2?

1. Injectable Objects

These objects do not have an identity of their own. They can be injected into constructors to be used as singletons or shareable objects. Examples include EventManager and CustomerAccountManagementService.

2. Non-Injectable Objects

Entities such as customers and products have their own identities and states. It is essential to know the exact instance you are working on. These entities cannot be directly initiated. A new instance must be created using the Factory design pattern and the create method.

What Is Magento 2 Dependency Injection?

Dependency Injection is a design pattern in Magento 2. It replaces the Mage class in Magento 1 to handle programming dependencies. DI removes direct dependencies between objects. It does this by injecting the required dependencies from an external environment rather than creating them internally. It simplifies future modifications and testing. It allows the mocking of required objects.

Components of Dependency Injection

• Service Object: Declares dependencies.
• Client Object: Depends on the service object and inherits its dependencies.
• Interface Object: Defines methods for the client to access the service's dependencies.
• Injector Object: Implements the service's dependencies and provides them to the client object.

Configure Dependency Injection in Magento 2

1. Via Constructor

This method injects dependencies through the class constructor.

/**
 * Save constructor.
 *  
 * @param Action\Context $context  
 * @param Builder $productBuilder
 * @param Initialization\Helper $initializationHelper  
 * @param \Magento\Catalog\Model\Product\Copier $productCopier
 * @param \Magento\Catalog\Model\Product\Type\TransitionManager $productTypeManager  
 * @param \Magento\Catalog\Api\ProductRepositoryInterface $productRepository
 */
public function __construct(
    \Magento\Backend\App\Action\Context $context,  
    Product\Builder $productBuilder,
    Initialization\Helper $initializationHelper,  
    \Magento\Catalog\Model\Product\Copier $productCopier,
    \Magento\Catalog\Model\Product\Type\TransitionManager $productTypeManager,  
    \Magento\Catalog\Api\ProductRepositoryInterface $productRepository
) {
    $this->initializationHelper = $initializationHelper;
    $this->productCopier = $productCopier;
    $this->productTypeManager = $productTypeManager;
    $this->productRepository = $productRepository;
    parent::__construct($context, $productBuilder);
}

Example: Magento\Catalog\Controller\Adminhtml\Product\Save

2. Via Method

This method injects dependencies through methods often used in APIs.

namespace Magento\Catalog\Api;

/**
 * @api
 * @since 100.0.2
 */
interface ProductAttributeManagementInterface
{
    /**
     * Assign attribute to attribute set
     *
     * @param int $attributeSetId  
     * @param int $attributeGroupId
     * @param string $attributeCode  
     * @param int $sortOrder
     * @return int
     * @throws \Magento\Framework\Exception\InputException
     * @throws \Magento\Framework\Exception\NoSuchEntityException
     */
    public function assign($attributeSetId, $attributeGroupId, $attributeCode, $sortOrder);

    /**  
     * Remove the attribute from the attribute set  
     *  
     * @param string $attributeSetId  
     * @param string $attributeCode  
     * @return bool  
     * @throws \Magento\Framework\Exception\InputException  
     * @throws \Magento\Framework\Exception\NoSuchEntityException  
     * @throws \Magento\Framework\Exception\StateException  
     */  
    public function unassign($attributeSetId, $attributeCode);

    /**  
     * Retrieve related attributes based on given attribute set ID  
     *  
     * @param string $attributeSetId  
     * @return \Magento\Catalog\Api\Data\ProductAttributeInterface[]  
     * @throws \Magento\Framework\Exception\NoSuchEntityException If $attributeSetId is not found  
     */  
    public function getAttributes($attributeSetId);  
}

Example: Magento\Catalog\Api\ProductAttributeManagementInterface

DI allows Class A to declare dependencies. Class B can use those dependencies without managing them directly. Class A uses an Interface class, and Class B implements it. It ensures a clear division of responsibilities by enhancing the structure's maintainability.

Ask for resources at the time of object creation instead of when needed. This improves the flexibility and testability of the code. It makes it easier for developers to understand and work with Magento's architecture.

FAQs

1. How do virtual types in Magento 2 differ from regular classes?

Virtual types in Magento 2 are special configurations in di.xml. They allow you to create variations of existing classes without writing new code. They are useful for argument replacement. Also, they help in customizing behavior without modifying the original class.

2. What is the preference design pattern in Magento 2?

Preference design pattern in Magento 2 replaces one class or interface with another. It is configured in di.xml. It is useful when you need to override or extend core functionality.

3. How does Magento handle events and observers?

Magento uses an event-driven architecture where specific actions trigger events. Observers listen for these events. They also execute custom business code when the events occur. This pattern allows for extension-based customizations without modifying core files.

4. Are there any situations where design patterns are dispensable in Magento development?

While design patterns are generally beneficial, some simple scenarios add unnecessary complexity. It is important to evaluate each situation. You can use patterns judiciously to balance code organization with simplicity.

5. How does Magento's approach to design patterns reduce conflicts among extensions?

Magento's use of design patterns provides a standardized way for extensions. This helps them interact with the core system and each other. Examples include dependency injection and service contracts. This approach reduces conflicts among extensions that change the behavior. They change the behavior of the system by providing integration points and APIs.

6. How does inheriting from Mage_Core_Model_Abstract in Magento relate to design patterns?

You can inherit after Mage\_Core\_Model\_Abstract class in Magento 1. This practice implements several patterns. Examples include Active Record and Observer. In Magento 2, this has been replaced with more modern design patterns and practices.

Summary

Magento design patterns help streamline development, improve code quality, and ensure scalable solutions. It helps users to:

• Allow for customization while maintaining core integrity.
• Ensure efficient resource management for separating business, presentation, and coupling logic.
• Enhance modularity and provide a stable API for extensions and integrations.
• Leverage injectable and non-injectable objects for proper dependency management.
• Use improved code flexibility and testability.

Consider Magento hosting services to improve development efficiency, maintainability, and performance.