Factory / Abstract Factory confusion
Asked Answered
D

2

14

After ~10 months of procedural PHP, I'm now trying to wrap my head around basic OOP principles and design patterns. This is a hobby, and I haven't nearly as much time as I'd like to pursue it, so please forgive the rather low level of this question.

My site (currently 100% procedural) is at heart a library. Visitors send the Library script 2 datapoints - an item type and item code.

Library.php uses the item type to select an include, and the include grabs the code to hit the database and then build the page.

Some examples:

[type]  [code]
 game    RoTo
 map     32
 unit    216

An example link would be library.php?type=game&code=RoTo

Everything works nicely as is, but as I get started with OOP I see obvious easy entry points and inheritance paths for "objectifying" this system.

class LibraryObject
{
    protected $_name;
    protected $_description;
}

class Game extends LibraryObject
{
    protected $_releaseDate;
    etc.
}

I'm also excited about the flexibility some well-written classes will give me.

The design pattern idea is tripping me up, though. It seems like a Factory pattern, but I'm confused about the differences between F and AF. I've read other SO questions specifically asking that question, and I've read the examples on OODesign but I feel like they're written in a different language and it's rather frustrating.

Perhaps if someone could explain it using my own data structures it would make more sense to me?

Sorry for the trouble.

Demineralize answered 18/1, 2011 at 1:58 Comment(0)
J
35

The difference between Factory and Abstract Factory is pretty simple. In the latter, the factory itself is abstract (!) and cannot be instantiated directly, but must be sub-classed.

Per example, Factory:

class Document {
   public function createPage() {
       return new Page;
   }
}

class LandscapeDocument extends Document {
   public function createPage() {
       return new LandscapePage;
   }
}

In Abstract Factory:

abstract class Document {
   abstract public function createPage();
}

class PortraitDocument extends Document {
   public function createPage() {
      return new PortraitPage;
   }
}

class LandscapeDocument extends Document {
   public function createPage() {
      return new LandscapePage;
   }
}

In short, the Factory pattern has a default implementation in the factory class itself. The Abstract Factory requires all sub-classes to implement their own version of the factory methods.

That's all there is to it.

Jenny answered 18/1, 2011 at 2:32 Comment(3)
Would I be correct in describing my library system as suitable for an Abstract Factory design pattern, given the description I posted?Demineralize
@Andrew: I believe that Abstract Factory would be more suitable to your use case, yes.Jenny
I'm sorry, but this answer is utter nonsense. See: Differences between Abstract Factory Pattern and Factory MethodPanicstricken
P
1

Here is another way you can look at it:

To clear the bushes:
A factory pattern is a creational pattern. That is it is used to create instances for use.

Factory Pattern

  • A creational pattern where the logic for creating the instance lies in the hands of the Factory class.
  • A Factory Pattern creates only one type of object instance. In your case it would create objects of type LibraryObject assuming that the LibraryObject is top most object in the hierarchy tree.

Abstract Pattern (Factory of Factories)

  • A creational pattern where the logic for creating the instance lies in the hands of the classes that implement the Factory interface / abstract class.
  • An Abstract Factory pattern can create objects of different types, so you can use the concrete implementations of Factory interface / abstract class to create objects of the types that you desire. That is why it is called a Factory of Factories.

A good reference would be this link below, I would suggest you read the Factory Method pattern as well:
http://www.oodesign.com/creational-patterns/

Peevish answered 20/1, 2015 at 11:31 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.