Magento’s Class Instantiation Abstraction and Autoload

If you're at all conversant with object oriented programming, the following line should look familiar to you.

$customer_group = new Mage_Customer_Model_Group(); 

We're instantiating an instance of the Mage_Customer_Model_Group class. However, if you were to search the Magento codebase forMage_Customer_Model_Group, you'd never find a single expression that looks anything like the one above. You would, however, see a lot code that looks something like this

$customer_group = Mage::getModel('customer/address'); 

By the end of this article, you'll understand the how and why of instantiating classes in Magento, as well as how to include custom Models, Helpers, and Blocks in your own modules.

PHP Autoload

Before we get into the nitty gritty of Magento's class instantiation abstraction, we need to spend a minute or two talking about PHP include files.

Prior to version 5, PHP didn't offer much guidance on how project files should be structured. PHP has a simple concept of including or requiring a file. You pass the include or require statement a string that contains a path to another PHP file

include('/path/to/file.php'); 

and PHP acts as though the code in file.php was part of your main program. There's no automatic namespacing, linking, packaging or any attempt to reconcile the context of the included files.

Over the years this has led every PHP shop and project to develop their own conventions as to how their base system/library code should be included. If two headstrong developers have a difference of opinion on how this should be accomplished, the resulting codebase quickly becomes a rat's nest of redundant includes and requires.

While PHP still doesn't enforce any particular strategy, PHP 5 introduced the concept of autoloading your class files. Developers can create an autoload function that will be called whenever an undefined classes is referenced anywhere in the codebase, with a single argument of the referenced class name.

For example, consider the following simple autoload function

function __autoload($class_name){     require('lib/'.strToLower($class_name).'.class.php'); } 

The team that uses this function stores all its classes in a directory structure that looks something like this

lib/customer.class.php lib/email.class.php 

While not suitable for every project, if used judiciously the autoload concept frees developers from having to care about when and where they include their class files, as well as enforcing/encouraging a consistent naming convention.

Magento Autoload

As you'd imagine, Magento's module system leverages the autoload feature heavily. While tricky to master, once you understand the naming convention, you'll know exactly where to find any Magento class is, as well as know where to place your own classes.

You can split all Magento classes into four parts that we'll call Namespace, Module Name, Class Type, and Name. Consider the The class mentioned above

Mage_Customer_Model_Group Namespace_ModuleName_ClassType_Name 

Namespace

A classes's namespace lets you know who's responsible for creation and maintain of the class, and helps prevent name collisions between modules. All Magento core modules use the Mage namespace, and the recommended convention is to use a version of your company name for your own modules.

ModuleName

All customization of Magento is done through modules, which are a collection of source code and config files that can be loaded into the Magento system. In the example above, the ModuleName is Customer.

Class Type

Without getting into too much detail, there are several broad categories of classes in Magento, including Model, Singleton, Helper, and Block.

Name

Finally, each class should have a unique name that describes its intended use or function. In the above example, this is Group.