in reply to RE: Object Heirarchy / Design
in thread Object Heirarchy / Design

That sounds reasonable; my only question would be in regards to the actual calling syntax. It seems to me that Obj::Input::DB->get( @params ) is a bit clumsy, and I'd prefer to use something a bit more neutral, like a simple string passed as one of the arguments, eg:
$myObj = Obj->get( "db", @args );
I suppose i'm answering my own question here, since the above is almost identical in terms of implementation to
$myObj = Obj::Input::DB->get( @params )

Replies are listed 'Best First'.
RE: RE: RE: Object Heirarchy / Design
by chromatic (Archbishop) on Nov 15, 2000 at 09:43 UTC
    That's easy enough. Just make Obj a wrapper around a more specific instance, like the DBI module you mention.
    package main; # example construction my $obj = Obj->new('Database', @parameters); my @data = $obj->get(@foo); package Obj; my %sources = { Database => Source::DB, XML => Source::XML, HTML => Source::HTML, }; sub new { my $class = shift; my $source = shift; my $source_obj = init($sources{$source}, @_); my $self = { source => $source_obj, }; bless($self, $class); } sub get { my $self = shift; return $self->{source}->get(@_); }
    Magic happens in the constructor :).

      While I agree with this in principle, I'm not sure I agree with the execution.

      I think that you'd really want Obj to return an instance of a subclass (e.g. Obj::DB or Obj::FlatFile).

      Then you maintain the consistency of the interface -- so that your objects all share the same methods and simply overload them as necessary, but the implementation specific to each type of object occurs in seperate classes/objects.

      I thought I remembered seeing something in Fastolfe's node, but I a quick look didn't come up with anything.

        The execution is fine.

        The constructor for Obj as chromatic wrote it will cheerfully construct things for subclasses.

        However his very good point is that there appears to be no point in having your readers and writers have the methods in Obj, or vica versa. It is very easy to just say, "inherit", but inheritance used too often loses the point.

        For serious food for thought, look through how LWP works. You will find a lot of classes, but things of different types (eg user agents, requests, responses) don't inherit from each other even though they interact quite a bit. And the design of the whole benefits from that.