Magento Design Patterns

Magento, IMHO, represents a PHP system that is built on well thought-out coding principles - reuseable design patterns being one of them. In terms of an example of a PHP system, I think it can be considered pretty cutting edge and therefore worth considering from an architectural point of view.

As I understand it, there are many design patterns that are available to the OOP developer. Seeing such patterns being put to use in an open-source system such as Magento allows a developer to view examples of such patterns in real use and in situ, rather than in examples that can sometimes be rather achedemic, and even a little misleading.

As such, I am wondering what patterns, other than the ones I have listed below, Magento programmers have used when developing for Magento.

As a note, I understand that some of these patterns are in place as a co开发者_运维百科nsequence of being built on the Zend Framework, MVC / Front Controller being a couple of them,

The obvious ones are:

Factory:

$product = Mage::getModel('catalog/product');

Singleton:

$category = Mage::getSingleton('catalog/session');

Registry:

$currentCategory = Mage::registry('current_category');

Prototype:

Mage:getModel('catalog/product')->getTypeInstance();

Event-Observer Pair:

# PHP
Mage::dispatchEvent('event_name', array('key'=>$value));

# config.xml
<config>
    <global>
        <events>
            <event_name>
                <observers>
                    <unique_name>
                        <class>Class_Name</class>
                        <method>methodName</method>
                    </unique_name>
                </observers>
            </event_name>
        </events>
    </global>
</config>

Object Pool:

$id = Mage::objects()->save($object);
$object = Mage::objects($id);

Iterator:

Mage::getModel('catalog/product')->getCollection();

Design Patterns Found In Magento in details

1. Model View Controller Pattern

Model View Controller, MVC for short, is a design pattern where business, presentation and coupling logic are separated. Magento heavily utilizes XML as templating-logic and HTML mixed with PHP files for its views. Models are backed by Varien’s ORM. Most business logic happens in the models whereas the controllers map the model-data to the views.

Because Magento its views are “fat” – they often contain a lot of logic – its not rare that views have an additional PHP class (the Block system) which will help with rendering.

2. Front Controller Pattern

The front controller pattern makes sure that there is one and only one point of entry. All requests are investigated, routed to the designated controller and then processed accordingly to the specification. The front controller is responsible of initializing the environment and routing requests to designated controllers.

Magento has only one point of entry (index.php) which will initialize the application environment (Mage::app()) and route the request to the correct controller.

3. Factory Pattern

As implied by the name, the factory pattern is responsible of factorizing (instantiating) classes. It’s widely used through the Magento code base and leverages the autoloading system in Magento. By defining an alias in a module its config.xml you are letting the factory know where it can find classes.

There are various factory-helper methods in the Mage core class and one of them is getModel(). It accepts an alias for a class and will then return an instance of it. Instead of having include calls scattered through the code base, the factory pattern will instantiate classes in an uniform way.

4. Singleton Pattern

Another way to retrieve an instance of a class, is to call Mage::getSingleton(). It accepts a class alias and before returning an instance, it checks the internal registry whether this class has already been instantiated before – this results in a shared instance. An example of where this is mandatory, is the session storage which should be shared through the code base instead of creating it anew every time.

5. Registry Pattern

All the singletons are stored in the internal registry: a global scoped container for storing data. It is not only for internal use. The Mage::register($key, $value), ::registry($key) and ::unregister($key) methods can be respectively used for storing, retrieving and removing data from the registry. The registry is often used for transferring data between scopes when they cannot be passed on, otherwise.

6. Prototype Pattern

Where the factory pattern (#3 on our list) stops, is where the prototype pattern continues. It defines that instances of classes can retrieve a specific other class instance depending on its parent class (the prototype). A notable example is the Mage_Catalog_Model_Product class which has a getTypeInstance method to retrieve the specific Mage_Catalog_Model_Product_Type with a specific subset of methods and properties not applicable to all products.

For example, the Mage_Downloadable_Model_Product_Type ultimately extends the Mage_Catalog_Model_Product_Type. If you are iterating over an order and want to call a specific method of a downloadable product, you will need to factorize it first with the getTypeInstance method of the original product.

7. Object Pool Pattern

The object pool pattern is simply a box with objects so that they do not have to be allocated and destroyed over and over again. It’s not used a lot in Magento other than for heavy tasks where resources can get limited soon, like importing products. The object pool (managed by Varien_Object_Cache) can be accessed with Mage::objects().

8. Iterator Pattern

The iterator pattern defines that there is a shared way to iterate over a container with objects. In Magento, this is handled by the Varien_Data_Collection which on its turn uses various baked-in PHP classes (like ArrayIterator) for having a more OO-interface to arrays. This ensures that model-collections will always have a common API to iterate over without being dependent of the actual models.

9. Lazy Loading Pattern

Lazy loading ensures that loading data is delayed until the point when it is actually needed. This results in less resources being used. One of the lazy loading behaviors of Magento is that of collections. If you were to retrieve a collection of products with Mage::getModel('catalog/product')->getCollection(), the database will only be touched when you actually access the collection by, for example, iterating over it or retrieving the count of models found.

10. Service Locator Pattern

The service locator pattern abstracts away the retrieval of a certain service. This allows for changing the service without breaking anything (as it adheres to its abstract foundation) but also fetching the service as seen fit for its purpose.

Ryan exemplifies this with database connections. Another example is that of Magento its caching mechanism where Mage::getCache() is a service locator by-proxy for the cache storage supplied by Zend or other vendors.

11. Module Pattern

Anyone familiar with Magento development has stumbled upon the module pattern. It basically defines that different domains are grouped into separate modules which function independent of each other and can be plugged-in to the main system as deemed appropriate. In an ideal situation, an implementation of the module pattern would make sure that each element can be removed or swapped. One of the protagonists of the module pattern in PHP is the Composer package manager.

Though Magento heavily relies on a modular architecture, its not modular to the bone. Certain functionality is heavily tied to the core and can not be easily changed. There is also the heavy usage of the super-global Mage core-class which introduces all sorts of system-wide dependencies not easily overseen.

12. Observer Pattern

Magento its event-driven architecture is a result of an implementation of the observer pattern. By defining observers (or listeners), extra code can be hooked which will be called upon as the observed event fires. Magento uses its XML-data storage to define observers. If an event is fired with Mage::dispatchEvent($eventName, $data), the data storage will be consulted and the appropriate observers for $event will be fired.

A few more:

Event/Listeners:

Mage::dispatchEvent('model_load_before', $params); 

And of course, MVC, with Views being represented by a combination of XML, PHP Classes, and PHTML templates.

Don't forget about Lazy Loading, which means that database access only occurs when strictly necessary. For example:

$collection_of_products = Mage::getModel('catalog/product')
->getCollection();
$collection_of_products->addFieldToFilter('sku','n2610');

The database query will not be made until you attempt to access an item in the Collection.

I think that the relationship between Mage_Checkout_Model_Cart and Mage_Sales_Model_Quote is a Bridge design pattern. As defined by wikipedia Bridge is meant to "decouple an abstraction from its implementation so that the two can vary independently". Thus, Cart seems to be the abstraction and Quote seems to be the implementation.

Service Locator

Allows overrides or renamed physical resources (e.g. Classes, DB tables, etc)

Mage::getModel('catalog/product') and $installer->getTable('customer/address_entity')

Following are design patterns : 1. Model View Control.

1. Singleton

2. Factory

3. Registry

4. Front controller.

5. Iterator.

6. Lazy Loading.

7. Observers( events )

In general in my point of view Magento uses its own unique implementation of most patterns, so it should not be made that much of a comparing among them.

For example in the past I have seen the Factory creational pattern as a class, which handles the instantiation group classes. In Magento the merged config xml file stores the all paths to models, blocks and helpers, in order afterwards in the development process the developers to specify only the unique identifier for the path slash and the actual class name. The Singleton and the Registry patterns also is different than the expected.