Re: Re: Constructor/Factory Orthodoxy

The parent/child knowledge issue sometimes is worth violating IMO -- again in conflict with standard OO. This may not have any bearing on this particular problem but one instance where I found it fits perfectly:

I have a set of file classes all derived from a common base class. Each file class represents a file accessed via some different transport (e.g., ftp, http, rsh, ssh).
Each file class in turn has a directory class. A directory is just a special type of that file, so it has all the file methods plus some add-ons only directories can do.
At construction time, all the caller knows is the file name. It's during construction, when the actual filesystem (or whatever) is consulted that knowledge of a directory arises.
If a file does find out it's a directory during construction, it simply morphs itself into its directory subclass by re-blessing itself into that class.

I like Perl's ability to elegantly address that pattern when it makes sense.

Comment on Re: Re: Constructor/Factory Orthodoxy

Replies are listed 'Best First'.
Re: ^3 Constructor/Factory Orthodoxy by simon.proctor (Vicar) on Feb 27, 2003 at 13:48 UTC
I had a think about your example and I think that its reasonable to do something like that. I think I'd probably do the same. However, I have been trying to think about how to get around your problem without doing this (purely for academic purposes) and the only thing I could think of was a variation on the Decorator pattern? Even then I'm not sure ;) Its nice that Perl has this flexibility, I am curious as to how this would be done in a statically typed language such as Java or if you wanted to practise a 'purer' OO approach. Again, purely for academic reasons. SP	[reply]
Re3: Constructor/Factory Orthodoxy by dragonchild (Archbishop) on Feb 27, 2003 at 14:32 UTC
re-blessing doesn't mean you violate parent-knowledge behavior. In fact, Policy, Manifest, and/or Factory classes would be a better way of doing this. Create a file object. The file object, during construction, finds out it's a directory. The file object will then either: Ask the Factory to for the classname to rebless to Give itself to the Factory and asks to be reblessed The factory or policy or manifest should be the one that maintains that knowledge and how to transform. ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply]