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

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 :).

Replies are listed 'Best First'.
RE: RE: RE: RE: Object Heirarchy / Design
by jreades (Friar) on Nov 15, 2000 at 21:37 UTC

    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.