Couldn't this be done using an Interface inheritence paradigm ? This course would be consistent with the OP expressed intent, because Thing::Backend::A isn't much different than my $obj = Thing->new(backend => 'A'); $obj->backend->do(); In this case Interface inheritance is actually more straight forward and more readable. However, I think that the OP's implied intent was to abstract the decision of which backend object to use from the user. If I were writing this it would of course use interface inheritance so that all the backend objects looked the same. I am personally more fond of the factory pattern, coming from java, however the composition pattern works just as well. For example:

package Thing;

# default constructor for all "Thing"s
sub new
{
    my ($class,%options) = @_;
    my $self = { %options };
    return bless $self, ref($class) || $class;
}

# abstract method stub
sub do
{
   my $self = shift;
   die ref($self) || $self . " did not implement do()\n";
}

package Thing::A

sub do
{
   my $self = shift;
   print "This is " . ref($self) || $self . "\n";
}

package Thing::B

sub do
{
   my $self = shift;
   print "I'm a really cool " . ref($self) || $self . "\n";
}

package ThingFactory;

my %dispatch = (
 'A' => 'Thing::A',
 'B' => 'Thing::B',
 '_default' => 'Thing::A',
);

sub createThing
{
   my ($class,%options) = @_;

   unless( exists($options{'thing'}) && $options{'thing'} )
   {
        return $dispatch{'_default'}->new(%options);
   }
   elsif( !exists($dispatch{$options{'thing'}}) )
   {
        return $dispatch{'_default'}->new(%options);
   }
   else
   {
        return $dispatch{$options{'thing'}}->new(%options);
   }
}

package main;

my $thing = ThingFactory->createThing('thing' => 'A');
$thing->do();
[download]

(Note this code is untested, but the the premise is sound, i may have missed a couple of parenthesis or curly braces)

Something else to note: ThingFactory::createThing's implementation is very simple, of course this will be as simple or complex as you need. Think about instead of the user deciding what thing he wants, having the user pass in some other info maybe some attributes of the thing they are looking for, then createThing becomes much more useful because you can make it know more about the implementations of Thing and not require the user code to worry about searching the implementations for what they want. This is the beauty of the Factory pattern.

Of course you should substitute createThing with your own logic for creating a Thing class but this was an example (I'm also a fan of dispatch tables =] ), a possibly more efficient way other than a dispatch table is to surround the constructor call in an eval such as my $thing = eval { "Thing::$options{'thing'}"->new(%options); };(again untested but it's the concept that counts) You do need the eval so it won't throw you program into fits if you don't have a Thing::C. Also the default is not a defacto part of the pattern, but for situations where it is appropriate I like to add that. Of course with perl TIMTOWTDI, however, I like to stick as closely to common OO standards (by that I mean what you mainly find in Java and other "pure" OO languages) as possible, even when perl affords me the opportunity to cheat (which it does a lot). That's a personal preference of mine, most people think i'm crazy for it. Ah, to each his own. Well, this post turned out to be a stream of conscousness(sp). Do with it what you will.