Practice
Design patterns are one of the first topics we'll look at. Many developers forget about them when building their applications. Patterns don't, in essence, provide a ready-made solution to a problem, but they are used as a basis for understanding and making sense of many "template situations" when writing code.
In Magento, patterns are a fundamental foundation that puts it a level above competing platforms. Everything is already available out of the box, and much of it is already implemented — you just need to know where it is and how it works. Let's briefly go over where and how the main patterns are hidden in Magento.
Model-View-Controller, MVC for short, is a design pattern in which business logic, presentation, and connecting logic are separated.
Magento actively uses XML as templating logic and mixed HTML with PHP files for its implementation. All models are based on Varien's ORM.
Most of the business logic is implemented in models, which is output to views through controllers.
This pattern ensures that there is one and only one entry point (in Magento this is the index.php file). All requests are tracked and routed to the designated controller, then processed according to the specification. The Front Controller (Mage::app()) is responsible for initializing the environment and routing requests to the specified controllers.
As the name suggests, this pattern uses the decomposition of a class into constituent subclasses with instantiation (creation of an object instance). It is widely used in Magento's native code and in the system core's autoloading. By assigning aliases in the config.xml file, we let the factory know where to look for the needed classes.
There are various helper factory methods in the Mage Core class (for example, getModel()). They accept a class alias and then return its instance.
Instead of using scattered include calls throughout the system core, the factory pattern gathers everything into one global class.
Where the Factory pattern's work ends, the Prototype pattern continues. It determines whether instances of classes can extract certain data from an instance
of another class depending on its parent class (prototype). A vivid example is the Mage_Catalog_Model_Product class, which has a getTypeInstance method
for extracting the specific Mage_Catalog_Model_Product_Type class with a certain set of unique methods and properties applicable to individual products.
Anyone who gets deeply acquainted with development on the Magento CMS sooner or later encounters the Module pattern. It determines how different domains are grouped into separate modules in such a way that they don't interfere with one another's functioning and can use functionality for operation from the module directory (scope) of the core system. But although Magento relies on a modular structure, its implementation inside the platform core is non-modular "to the bone." Certain functionality is heavily tied to the center of the system and cannot be easily changed. An example is the same super-global Mage class, which introduces various system-wide dependencies. These dependencies are hard to control.
Another way to get a class instance is by calling the Mage::getSingleton() method. It accepts a class alias and, before returning an instance, checks the internal registry for the presence of one already instantiated. An example of its use is the session storage, which must exist in only one instance.
All singleton instances are stored in an internal registry: a kind of global scope container for stored data. But it's not only for internal (private) use. We can freely take the data we need from it for our own purposes.
The methods Mage::register($key, $value), ::registry($key), and ::unregister($key) can be used, respectively, to store, retrieve, and remove data.
The Registry pattern is often used to pass data between different scopes (code directories). In Magento there are three of them: core, community, local.
Magento, with its event-driven architecture, makes extensive use of the Observer pattern. By definition of observers (or listeners), additional code can be hung on a special event listener, which is invoked as the event being observed occurs. Magento uses its own XML data store to define observers. If an event is dispatched as: Mage::dispatchEvent($eventName, $data), Magento's data store will be notified and the corresponding observers will fire their events ($event).
Described above is only part of the main patterns used in Magento. Some of them have undergone changes compared to the classic representation of patterns. But that's a good thing, because design patterns exist only to help developers understand the general idea rather than deploy a literal implementation.
Comments