[OT] Perl OO Question.

[Andy Wardley]

McGlinchy, Alistair wrote:
> Perhaps I need a separate class that knows about MainframeFile,
> MainframeFile::SNI and MainframeFile::CCU and does the choice for me.
> If so what would it look like?

As already noted, an Abstract Factory is the way to go.

A more general rule of thumb that I have found useful is that whenever
you find yourself with multiple implementations of a "thing" then you'll
probably want to create a class representing the notional set of all
"things" to handle create/fetch/store/update/delete or whatever other
operations are relevant.  An abstract factory traditional only relates
to the creation of things, but there's nothing to stop you from creating
a more general "manager" class that includes other operations.

So My::Files is the manager class for My::File, My::Images for
My::Image, My::Ponies for My::Pony, and so on.

	my $things = My::Things;
	my $thing  = $things->fetch('some/id/for/a/thing');
	# $thing is a My::Thing or subclass thereof.
         $things->store('/another/id' => $thing);
	$things->delete('/a/third/id');
	# etc...

This pattern is particularly applicable to database tables and other
data stores where you want to abstract the underlying implementation.
It allows you to switch your Things from a filesystem store to a
database table, for example, without having to rewrite your application
code.

A