The stupid question is the question not asked | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
...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 In reply to Re: Re: (jeffa) XML Resume Module design
by agentv
|
|