Polymorphism is your friend - definitely subclass! This way you can define an output method and just call it on which ever object you instantiated.

Why? That way suggests that an ‘HTML resumé’ is an inherently different kind of thing to a ‘PDF resumeé᾿, that they are distinct classes of object in the same way that camels and llamas are distinct. (Well, OK, not in quite the same way.)

I reckon the opposite is true — there isn't such a thing as an ‘HTML resumeé’ or a ‘PDF resumeé’ in terms of what it models. You can have a resumé which contains data representing your personal details and work history. You can do several things with that data, including emitting it in particular output formats.

But it seems daft to have a object which in effect means “the data in this instance represents my life achievements but it can only be displayed as a PDF” and forcing you to copy the data to another instance just because you want it to be emitted differently.

Smylers

"But it seems daft to [force] you to copy the data to another instance"

I should have placed $self inside base instead, and allowed the subclasses to format it in some way - but i was trying to keep it simple. The idea is that the base clase contains the data in a Perl data structure and the subclasses are responsible for flitering that data structure into a particular format. Let me try again:

package Factory;

sub create {
   my $class = shift;
   my $obj = 'Base::' . shift;
   return $obj->new();
}

package Base;

sub new {
   my $class = shift;
   my $self = { thing => 'foo' };
   return bless $self,$class;
}

package Base::Bold;
use base 'Base';

sub output {
   my $self = shift;
   return '<b>' . $self->{thing} . '</b>';
}

package Base::Italic;
use base 'Base';

sub output {
   my $self = shift;
   return '<i>' . $self->{thing} . '</i>';
}

package main;

my @things = (
   Factory->create('Bold'),
   Factory->create('Italic'),
);

print $_->output,$/ for @things;
[download]

And an HTML resume is different than a PDF resume: HTML and PDF are adjectives to the noun resume - an adjective qualifies, distinquishes, and specifies - hence, an HTML resume is one kind of resume (Resume::HTML), and a PDF resume is another kind (Resume::PDF). I you don't like this, then how about naming them Resume::AsHTML and Resume::AsPDF instead? ;)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

...you know, I was with jeffa on this until I read your post smylers, and now I think I partially agree with you.

Purists will argue that here are good reasons to subclass and there are lame reasons. I think this question falls into the grey area where I believe that it's "six of one, half-dozen of the other."

From the standpoint of extensibility and maintenance, there's little difference in my mind between supplying a new method in one class, or creating a new subclass. The effect of polymorphism makes it simple to select the method name if you use subclasses. But I don't think there is compelling as a reason for the approach.

I did find it instructive to consider the implications on memory use (and processing time) required to convert an XML resume' into an HTML resume' when each is implemented as a different type of object. If you simply supply different output methods, there's only one object ever put into memory. If you have different object types, then the conversion does require a copy operation. (I don't know if it's a big deal at this scale, but it is a consideration.)

I don't think it matters in this case overall, which approach you take. *BUT* I don't think it's "daft" (or daft enough) to go with the subclass approach. And if one of your objectives is to study and learn more about object design, then it's a good thing to do.

---v

Ooops. Didn't notice usernames were case-sensitive, so failed to log in before posting the above. Apologies.

Smylers