The idea behind your system, it seems to me, is that you want objects that are basically input-output neutral: they can be read from anywhere, and they can be written to anywhere. So what you want (and it sounds like what you have) is a series of polymorphic input and output drivers, such that you can provide a transparent transparent interface to the various input and output sources.

With that said, then, I would have one main object that doesn't inherit from anything. That object, in my system, would be of type "Obj". That's it. It would maintain *state* about its input and output drivers, so that when it came time to read and write this object, you could dispatch to the appropriate driver. So I might say:

    my $obj = Obj->get('DB', @params);
[download]

• load the Obj::Input::DB class (easy; just use require of eval "use")
• do something like

      Obj::Input::DB->get(@params)
  [download]

• give you back an object blessed into Obj

The reason I would bless my object into Obj, rather than into a driver-specific input class, is that I find that confusing: your object is generic, and it's not tied to a particular input class. So why add restrictions that aren't already there?

With respect to inheritance, I'd have a main Obj class that inherits from nothing. That's your main object class. Then either one of two things:

• Obj would provide a generic interface to input and output: "get" and "put" or whatever you want. Then the input drivers and output drivers would inherit from Obj.
• You'd provide some abstract classes Obj::Input and Obj::Output--abstract drivers--that don't do anything, but which provide the interface to your drivers that *do* do something. Your input and output drivers would then inherit from these classes.

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 );
[download]

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 )

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(@_);
}
[download]

Magic happens in the constructor :).

I would have your object contain two other objects, one for input and one for output. The connect method could then be implemented something like this (untested):

sub connect_read {
  my $self = shift;
  my $class = shift;
  $class = "Obj::Driver::$class";
  # Load the class if need be then instantiate
  require $class;
  $self->{input} = $class->connect_read(@_);
}
[download]

For both types of class (input and output) I would define a base class that is worthwhile to inherit from. For instance many of your drivers might need a number of rather low-level functions, but in your object code you may want to talk to a rather high-level functions. Well in your base class put the layer of obvious functions between the simple functions your drivers need to provide and the complex functions you would like to call. Then a driver only need inherit from the base and write a set of low-level functions, and the high-level functions will just work.

This brings up some other questions that I forgot to bring up.
1. How should logging be handled from these input classes? Obviously, they should all log through a standard interface, but due to the fact that they're not direct subclasses, I can't simply call $self->log( $msg ) or anything like that.
2. If there is an object hierachy such as follows:

   package Obj;
   
   package Obj::Input;
   @ISA = 'Obj';
   
   package Obj::Input::Type;
   @ISA = 'Obj::Input';
   [download]

   then Obj::Input::Type is inheriting from Obj, which doesn't make sense, since Obj::Input::Type isn't an Obj. But it should have access to some of the 'utility' functions provided by Obj. Those utility functions should somehow be provided by Obj::Input, which should also definitely by in Obj::Input::Type's @ISA.
   phew.

As tilly wrote: Obj::Input::Type doesn't need to inherit from Obj. If those "utility" functions are needed by both Obj::Input::Type and Obj, then they should be broken out of Obj and moved into their own utility class.

I don't know what your "utility" methods are (perhaps you mean logging, etc.), but my personal preference is this: if from a logical perspective it doesn't make sense to have them methods of Obj, then they shouldn't be declared as methods of Obj. In my opinion, it doesn't make sense for an Obj to have a "log" method. Why should it? How is "log" acting on, or acting with, or have anything to do with an Obj object? I don't think it does. If you come at it from that perspective, I think it may be a bit clearer what methods belong in what classes.

Why would Obj::Input bother inheriting from Obj? What does either Obj or Obj::Input get from this?

Think about your classic diagrams with Dog and Cat inheriting from Animal. Well Animals generally contain four instances of Leg, that doesn't mean that a Leg is an Animal though!

Instead Obj::Input exists for the purpose of containing useful utility methods for drivers to use. Your Obj class just assumes the interface it needs will work.

As for logging (if you want it), provide a logging method in your base class, then you do just call the method.

Also, be sure to take a good look at the DBIx hierarchy before beginning your design and coding.