Sometimes it depends on your user interfaces to your object. Perl's oop, on a basic level, has no security behind it, so any method you use for changing an attribute or state of an object for your factory, is available to the developer using your object. When you maintain state internally to your object, that may be a bad thing. i.e. if you have a linklist like object, and you create a method called set_size which just sets an internal variable for get_size to report back a number, some chucklehead, wrongly, and idiotically, if not documented, may try and use this method. Now your get_size will be off. But as they say, if you have no buisness being there, don't be surprised if I have a shotgun. :)

I only raise the point, as some other OOP implementations, java, ruby, python, c++, have different levels of encapsulation ability and security. In perl, it may be a silly thing, but in others, it may matter more.

cheers

Classes that serialize themselves (toXml, toYaml, whichever) typically have the saving/loading embedded in that class. Keeping code in one place prevents the need to dual-maintain as many files. However, yes I agree that if multiple types of serialization are needed this could clutter up the class somewhat. The answer is: there is no good answer, pick what you like.

I find a Car::fromXml($foo) method to be pretty elegant. A factory is definitely useful when we need to churn out things that conform to a sequence or that way conflict with one another, such as if we need to roll cars off the line with increasing VIN numbers :)