Design Patterns in Magento

Magento its architecture is sometimes deemed overly engineered. If we look at it from a helicopter view,
commonly used design patterns are easily spotted. Here are 12 of them.

Introduction
A software design pattern is a reusable solution to an often occurring problem. This doesn’t mean that software
is better if it has more design patterns. Instead, a good software engineer should be able to spot the problem and
implement the pattern instead of introducing implementations without purpose. The earlier behavior is leadingly
noticeable in Magento, where most if not all design pattern-implementations have a purpose.

This is a compilation of an article-series which originally appeared on Ryan Street’s blog (@ryanstreet).

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.

In addition to using modules, events can be used to customize existing logic without touching the existing code.

Conclusion
Hopefully these 12 design patterns, give you a bit better understanding of the architectural decisions made in
Magento. Not all design patterns found in Magento are implemented as defined by the original literature. This is
perfectly fine, because design patterns are there to help with solving common problems as seen fit, instead of
deploying verbatim implementations.