When to factory?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

When to factory?

Post by neophyte »

So what signs indicate to you that you should consider a object factory of one sort or another? If one class instantiates another should you do it with a factory? Can you have factoryitis? :p Should you use a factory if the name of the class being instantiated is dynamically class:

Code: Select all

$obj = new $className;
Whaddya think?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

So what signs indicate to you that you should consider a object factory of one sort or another?
Hmm, that's an interesting question. A good way to figure out when is to ask yourself what the consequences of using a factory are (ripped from GoF)

- "It isolates concrete classes": the client calling the factory only knows about the interface, not the implementation of the instantiated classes
- "It makes exchanging product families easy": self-explanatory
- "It promotes consistency among products": since they're so exchangeable, the developer is motivated to make them as consistent so that this exchange can actually happen
- "Supporting new kinds of products is difficult": if you have lots of factories, you'll have to modify a lot of code to add a new product

Note that there are varying strengths of factories. The above described is an "Abstract Factory", but you can also have a "Factory Method" which looks like this:

Code: Select all

$obj = $this->newClassName();
Prevents you from having to create an entirely new factory class but gives you a little less flexibility/interchangeability. Personally, I would see if this would work before going with a full-fledged factory object.
If one class instantiates another should you do it with a factory?
If you're a stickler about dependencies to interfaces not implementations, yes. Once again, however, it doesn't have to be an object factory, it can be a factory method.
Can you have factoryitis?
Yes. Use your good judgment. The golden rule of refactoring: the first time, just do it. The second time, do it but cringe. The third time, refactor!
Should you use a factory if the name of the class being instantiated is dynamically class
This is more reflection, so whether or not to use a factory is up to you. I would.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Well, if you think about what a Factory does it might be clearer. A Factory creates objects that it is pre-programmed to create. The objects are often polymorphic, but don't have to be. I think the key is that it knows specifically how to create those objects. That smarts is the power if the Factory because the interface is usually simple. Contrast the Factory with similar patterns like the Registry or Locator that do not know specifics about the objects they provide.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Some reading (shameless plug): Factory Pattern, Abstract Factory Pattern.

The way I look at it, is that an object can be instantiated in two broad ways. The first is that determining which object to create is either simple or limited, i.e. the decision is fairly easy and it require no complex decision making. In this case I'd try to avoid a Factory object or method. The second scenario is where the determination is complex, perhaps where the object instantiated depends upon some third element that is only known at runtime (config setting, state, etc.). In this case, a Factory can come in useful since it can shift all the decision making to a third object (or simply a method in the class) and prevent duplication of the decision making code across multiple classes.

My rule of thumb is to avoid Factories unless there's duplicated decision logic involved. Factoritis is a valid concern but usually when to use a Factory is fairly intuitive.

An Abstract Factory is more complex. While a Factory creates Objects, an Abstract Factory creates Factories (or at least shortcuts to the created Factory's createInstance() method). The example I gave on the PFP website was where Factories handled the instantiation of Database Abstraction classes. There was one Factory per alternative DB Library (ADOdb-Lite, MDB2) since each is instantiated differently and an Abstract Factory which handled deciding which Library (and hence which Factory) needed to be instantiated.

Note that a significant advantage of using Factory/Abstract Factory is to remove duplication of decision/creational code. A broad pointer to when its use might be warranted.
User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

Post by neophyte »

Thanks for the posts guys. That really clears things up for me. The keys being: elimination of duplication and/or isolate complexity. And then consider a factory method first and then a separate class.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Do we not think it's a good idea to *always* use a factory if you're going to use 3rd-party libs or classes? If you've scattered your code with lines which create new instances of a 3rd party class then somewhere down the line the developers of the project change the naming etc (like I've done before!) then a factory would save you a lot of grepping and replacing.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

The keys being: elimination of duplication and/or isolate complexity.
Seems covered by above? If using a 3rd party library (which I do all the time) I usually abstract it's creational logic. Aside from preventing duplication, it makes switching between alternate libraries simpler.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Yes, using abstraction is always a good thing. Have a class of your own instantiate the 3rd-party class then write callback/proxy type methods to operate on the third party class. Overhead is negligible and functionality can usually be re-worked if the class is switched to another one.

I always think about abstraction as providing more flexibility to the developer by providing more layers to work with and hence, more places to adjust behaviour but on top of that abstraction helps to maintain an iterface in a regularly changing environment.
Post Reply