I want to build three sites in PHP. I’m doing this as slowly, thoughtfully and carefully as I can, to learn as much about things like OOP and software architecture as possible.
From past experience I already know there will be a time when I will be glad to have logging functionality. I probably want to have different types of logs, by which I mean that in a .ini file, I want to be able to specify if logging should go to a text file (perhaps a tab-delimited or CSV file), a database table, or smoke signals. I’d have (let’s say) a Logger class, which would define, for example, an AddEntry() method. For each log type, I’d make a subclass that knows how to log to CSV file, write to a database or kindle a fire, respectively.
Since I know I will want to have an instance of a subclass, but I won’t know which subclass to instantiate until runtime, I figured I’d use the Factory Method pattern. However, When I look at its Wikipedia article I’m noticing that the Creator and ConcreteCreator have a different type than the Product, if I’m reading the UML correctly. My question comes down to this:
I want to have the factory method as a static method of the Logger base class itself. If I do that, am I setting myself up for a trap that I’m not seeing yet? Is there a reason why the Creator and ConcreteCreator should be of a different type than the Product?
It doesn’t have to be, no.
One example I can think of is in the .NET Framework in System.Net.WebRequest.Create(). It will return an object of a class derived from WebRequest, based on the protocol part of the URL passed to it.
However, there are problems with this.
You cannot inject a factory, if it’s a static method of the type being generated. (Well, in .NET, you can inject it as a Func<WebRequest>, but this still isn’t as ideal as injecting a factory object.)
It’s also not as neat, when you come to extend the factory with your own class. If there were a standard WebClientFactory class, with an interface exposing a Create method, I would be able to wrap that up in a CustomWebClientFactory, using the same interface and the calling code would never know the difference.
These are fairly trivial concerns, but your question is a fairly trivial one. Turn it around and ask yourself this: Why shouldn’t you use a Factory class for the Factory method?
1
They should be of different types because one is a Factory, the other is the type of object that the Factory produces.
In your case you can have a LoggerFactory and distinct subclasses of the Logger base class. The factory class will generate one of the subclasses of Logger based on the arguments given
Let me attempt to clarify: from the wikipedia page: “Creating an object often requires complex processes not appropriate to include within a composing object. The object’s creation may lead to a significant duplication of code, may require information not accessible to the composing object, may not provide a sufficient level of abstraction, or may otherwise not be part of the composing object’s concerns”
In essence, you’re using the factory object to remove alot of the bootstrapping code from the constructor of the type of objects that the factory will create.
Having the factory and it’s constructed objects share the same class does not solve the separation of concerns issue since the code would be in the same class.
3
The Factory and Product should be different classes.
The single responsibility principle states that every class should have a single responsibility. If a class was responsible for both implementing factory as well as logging, that would be two responsibilities.
More at http://en.wikipedia.org/wiki/Single_responsibility_principle
1