What if I could make the base class dog smarter and have it instantiate the subclasses for me?

For those who don't know this approach of having a single class instantiate different subclasses depending on the arguments is a common design pattern called an Abstract Factory (or sometimes Kit). If you keep an eye out you'll start seeing it everywhere (e.g. DBI instantiates different classes depending on the arguments to connect).

Class::Factory provides a little framework for rolling this sort of stuff together if you don't want to do it yourself.

my $class=ref($proto)||$proto;
[download]

my $class=ref($proto)||­$proto;
[download]

I understand the reasons to avoid this construct.

But if you avoid it, then you need to replace it with something. Unfortunately, although I often see this construct derided, I very seldom see suggestions for what to replace that line with (even when I come out and ask for it). The most straightforward replacement is unacceptable to me. See Re^2: A few Perl OOP questions. (disparaging) for why.

I also consider the objections to this to be rather minor in impact in a lot of practical situations and appreciate the "sloppy" advantages of $obj->new() in a lot of pracitcal situations. So I consider this construct to be a net win for simple OO Perl classes in many cases.

I also provide an alternative to it in (tye)Re: Private Class Methods.

- tye        

From the article you can't see yet:

But here's the problem. When I survey experienced object-oriented programmers, and ask them what they expect new means when called on an instance (without looking at the implementation), the result usually divides rather equally into three camps: those that go "huh, why would you do that" and think it should throw an error, those that say that it would clone the object, and those that say it would copy the object's class but not the contents.

So, no matter what you intend if you make your new do one of those three things, two thirds of the people who look at it will be wrong. It's not intuitive. So, don't write code like that, and especially don't just cargo-cult that from the manpage into your code. If you want an object like another object, use ref explicitly, as shown above. If you want a clone, put cloning code into your package, and call clone, as we saw earlier.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

      eval " use $breed; " ;
[download]

Also, in true merlyn fashion, it looks like eval in this string context makes you have unsafe doggies if you are using your dogs on a web site and allowing input of the doggie type in a text field.

$dog = ' strict; doEvil(); ';
[download]

I also think the strange use of dog as a factory class to produce subtypes of dogs is a little odd-form from an OO form, and that most OO purists would frown on the eval and use of reflection to pick subclasses. But I come from a very non-Perlish OO background, so this is just my two cents.

In conclusion, if we want to call this a tutorial, I say this should be a tutorial on the factory pattern, not a tutorial on polymorphism. Polymorphism is a much more general concept, and we skip over that generality by starting with the factory piece first. I would be interested to see if the factory could be made without using eval, as well...I think it can, especially if the dogs were loaded previously in a more-safe matter. But hey, maybe we don't have to worry about unsafe loading of doggies -- they do allright in the back of a pickup truck usually :)

Anyway, cool stuff, just a few ideas thrown out here. *yelp*.

Polymorphism is a much more general concept, and we skip over that generality by starting with the factory piece first.

See my reply below for why this isn't a good example of polymorphisim anyway. Update: blue_cowdawg's update fix the OP's polymorphisim issue.

I would be interested to see if the factory could be made without using eval, as well...I think it can, especially if the dogs were loaded previously in a more-safe matter.

It can using require $path_to_breed; instead of eval "use $breed;";. But it ammounts to almost the same thing, except that you have to specifiy the path to the breed file instead of the traditional 'module::name' format. As you say, it's also possible to load all the subclasses before anything is called, but that could get very inefficient fast.

My favored solution would be to map a breed via a hash:

my %breeds = (
    cocker   => 'dog::cocker', 
    setter   => 'dog::setter', 
);

sub new 
{
    my $class = shift;
    my $breed = shift;
    
    my $self = { };
    if($breed) {
        my $breed_class = $breeds{$breed};
        eval " use $breed_class ";
        die $@ if $@;
        $self = $breed_class->new();
    }
    else {
        bless $self, $class;
    }

    return $self;
}
[download]

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

As you point out, using a constructor on an existing object is something unnatural; I agree that ref($proto) should be avoided in normal cases.

However, there are times when you specifically want to clone or template a new object (e.g. Class::Classless). I you are doing something like this, you should make it clear in the POD that this method call is available, and precisely what it does. This should state (if this is the case) that new can be use both as a class method call and an object method call.

Also, as part of the POD, it forms part of your interface contract. You should write tests which exercise all the options and prove that your code matches what the POD expects to happen.

My $0.02

--
I'm Not Just Another Perl Hacker

$self= new $breed;
. . . 
bless $self,$breed;
[download]

I don't think this will do what you want. This will re-bless the reference into the dog package, which means that if you asked for a 'cocker' breed, any methods that dog::cocker overrides won't be called. Instead, the methods in dog will be called. Update: Read the code wrong--ignore this pargraph.

Which is really unfortunate, since it could be quite useful to override the bark method in your final example. Instead of checking if this instance has a voice attribute that is true, the subclass would already know and Do The Right Thing. That's where polymorphism starts becoming powerful.

I don't think this will do what you want.

Actually it does. The code was actually tested before I posted it. What you see is what I got.

---

Peter L. Berghold -- Unix Professional Peter at Berghold dot Net
	Dog trainer, dog agility exhibitor, brewer of fine Belgian style ales. Happiness is a warm, tired, contented dog curled up at your side and a good Belgian ale in your chalice.

I see where I went wrong. I read the above as bless $self, $class instead of bless $self, $breed.

In any case, I still think that if you want this to be a good tutorial on polymorphism, some of the subclasses should override bark. As it is, it doesn't take advantage of polymorphism.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated