Jump to content

OOP - Factory Pattern


benanamen

Recommended Posts

I ran across the following example of a Factory Pattern. My question is, why would you have all this Factory code when you could just call one of the extended button classes that you need?

<?php
abstract class Button {
    protected $_html;

    public function getHtml()
    {
        return $this->_html;
    }
}

class ImageButton extends Button {
    protected $_html = "..."; //This should be whatever HTML you want for your image-based button
}

class InputButton extends Button {
    protected $_html = "..."; //This should be whatever HTML you want for your normal button (<input type="button"... />);
}

class FlashButton extends Button {
    protected $_html = "..."; //This should be whatever HTML you want for your flash-based button
}

class ButtonFactory
{
    public static function createButton($type)
    {
        $baseClass = 'Button';
        $targetClass = ucfirst($type).$baseClass;

        if (class_exists($targetClass) && is_subclass_of($targetClass, $baseClass)) {
            return new $targetClass;
        } else {
            throw new Exception("The button type '$type' is not recognized.");
        }
    }
}

$buttons = array('image','input','flash');
foreach($buttons as $b) {
    echo ButtonFactory::createButton($b)->getHtml();
} 
Link to comment
Share on other sites

If you know that you want a FlashButton then go ahead and use that. But if all you know is you want a $b button then you don't very well want to have to go through the work of deciding which class to use, right? Easier to have some other code do that for you.

Link to comment
Share on other sites

The factory is an abstraction layer which provides more flexibility than instantiating objects directly.

 

When you just put hard-coded Button subclasses into your code, you're restricted to those exact classes once and forever. You cannot switch to a different implementation. It's also your job to prepare everything for the object instantiation, which can be a lot of effort for complex classes (not in this trivial example, of course).

 

The Factory Pattern is smarter than that:

  • The factory decides which class is instantiated. You can plug in a different class at any time by subclassing the factory.
  • Choosing the right implementation can also be more sophisticated than mapping strings to classes. The factory is free to choose the optimum based on any parameter.
  • The entire preparation procedure is delegated to the factory. This can greatly simplify the code.

However, the Factory Pattern is now often replaced with Dependency Injection.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.