2

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?

Improve this question

3 Answers 3

Reset to default
6

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?

Improve this answer
1
  • 1
    Java's Integer.valueOf follows a similar pattern as does the InetAddress.getByXYZ methods.
    – user40980
    Commented Apr 10, 2013 at 21:04
3

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.

Improve this answer
3
  • Basically, your answer says: "they should be different types because they should be different types". I don't understand why they have to be of a different type. Can you clarify that? Also, am I right in assuming that you mean Logger instead of Factory in that second paragraph?
    – toon81
    Commented Apr 8, 2013 at 18:37
  • yes, I just corrected that.
    – Marcos Savoury
    Commented Apr 8, 2013 at 18:46
  • 1
    To make it very simple. If you put it in the Logger base class then the base class has to know about all the different types that derive from it. That breaks at least a dozen "good-practices" rules. Plus the base class has to be modified every single time you derive a new class from it. Ideally, base classes should almost never change. Also, Marcos's main point is that your Logger class may end up having to drag in lots of dependencies that have nothing to do with a logger to instantiate the concrete logger instances. Why does a text logger need to inherit database stuff?
    – Dunk
    Commented Apr 10, 2013 at 20:30
1

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

Improve this answer
1
  • 2
    While I understand that your answer is correct, for the right reason and I do get what you are saying. I don't find the single responsibility principle to be all that useful in practice or in trying to describe a "why" to someone. Of all the good practices people preach, it is by far the least helpful as a guide. After all, if the factory knows how to create 5 different logger types, is that 5 different responsibilities? Going the other direction, if the LoggerBase class implemented the Factory then by saying it does Logging Management, all of a sudden it has 1 responsibility.
    – Dunk
    Commented Apr 11, 2013 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.