Conceptual Question About Classes and SubClasses

~~David~~ has asked for the wisdom of the Perl Monks concerning the following question:

I have a conceptual question about setting up classes that I would like to straigten out before I get too far on this project. I have three classes, CLASS::A, CLASS::B, and CLASS::X. CLASS::A and CLASS::B inherit from CLASS::X generic methods common to both CLASS::A and CLASS::B ( I used use base 'CLASS::X' ). Now, CLASS::A and CLASS::B are very generic and re-usable, but I need to use them in an application where I don't want to cram a bunch of project specific methods into them.
Should I add the project specific methods into CLASS::A:PROJECT which inherits from CLASS::A? Is this the correct way to do this? Is there a better way? Or am I completely off track.
Any feedback would be greatly appreciated.

Comment on Conceptual Question About Classes and SubClasses Download Code

Replies are listed 'Best First'.
Re: Conceptual Question About Classes and SubClasses by merlyn (Sage) on Aug 20, 2009 at 15:43 UTC
If your CLASS::A object doesn't have the behavior you need for your project, and would benefit from this extra behavior, you could either subclass CLASS::A as you've described, or compose a project-specific object that includes a CLASS::A object as an instance variable (member). Both ways have merits and downsides, and without knowing more about your application, I can't recommend one over the other. -- Randal L. Schwartz, Perl hacker The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.	[reply]
Re^2: Conceptual Question About Classes and SubClasses by ~~David~~ (Hermit) on Aug 20, 2009 at 15:56 UTC
Thank you for your reply. If I added the additional information, would it change the way you lean: I would like my "subclass" of CLASS::A and CLASS::B to share a common set of methods. My project specific methods should work independently of which class they are working on. For instance, whether or not I have A or B, i would like to `X->validate` them... If I sub-classed them, I think I would have to write two `validate` methods, in each subclass. I was trying to avoid that. Again, thanks for the help... I am not a programmer by trade, I am a chemical engineer so need some conceptual help!	[reply] [d/l] [select]
Re^3: Conceptual Question About Classes and SubClasses by jethro (Monsignor) on Aug 20, 2009 at 16:49 UTC
I believe the right approach is to have a method in X that validates whatever is to validate in X. If you can make that method generic, so that it would work for A and B too, even better Any subclasses for which X->validate does everything that is to do are finished now. Any subclass that has to do something more would have their own validate method. That method would then call the validate method of the superclass ($self->SUPER::validate) and if that returns ok, validate the additional stuff of the subclass. As you can see, you probably need a validate method in A and in B, BUT you don't need to write any code twice.	[reply]
Re^4: Conceptual Question About Classes and SubClasses by ~~David~~ (Hermit) on Aug 20, 2009 at 21:36 UTC
Re: Conceptual Question About Classes and SubClasses by jethro (Monsignor) on Aug 20, 2009 at 16:19 UTC
You could do that (CLASS::A::PROJECT inherits from CLASS::A), or keep the project-specific parts together in the applications realm, i.e. PROJECT::CLASS::A inherits from CLASS::A.	[reply]