Re^2: Advice on OO Program structure & organization

I too prefer this approach. Most of my object constructors take a list of pairs of attributes, check them for sanity, and set useful defaults if needed. They don't load or save or anything like that.

Instead, I use an external class that knows how to load, save, and instantiate many types of objects. In pattern language, this is a Factory.

It's especially nice because it aggregates the loading and saving into one place, conceptually unrelated to the objects themselves, which otherwise would have non-behavioral code mixed in with normal methods. It also allows the flexibility to change the serialization format almost trivially.

Comment on Re^2: Advice on OO Program structure & organization

Replies are listed 'Best First'.
Re^3: Advice on OO Program structure & organization by exussum0 (Vicar) on Dec 11, 2004 at 16:33 UTC
A minor squibble. Not a criticism at all, as there are multiple right ways.. 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 ---- Give me strength for today.. I will not talk it away.. Just for a moment.. It will burn through the clouds.. and shine down on me.	[reply]
Re^3: Advice on OO Program structure & organization by Anonymous Monk on Dec 13, 2004 at 17:04 UTC
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 :)	[reply]