Jenda Krynicky wrote: > From: Steve Bertrand <st...@ibctech.ca> >> My ISP management project which started out as a learning experience has >> grown into a system that currently contains 10 modules. The entire >> system is object-oriented. >> >> While reviewing my POD to ensure that I've been keeping it up-to-date >> properly, and so that I can still easily understand the API at the >> documentation level, I've noticed that two of my modules have >> subroutines that only perform global tasks, and don't need to be >> object-oriented at all. >> >> Is it recommended that I stick with the overall style of the project by >> making all of the modules object-oriented, or is it better to create >> procedural modules when objects are not required? > > Depends. Not on the project or the code, but rather on the person you > ask. If you ask me ... yes, it's perfectly fine to use OO only where > it actually helps with something and plain old procedural interface > where it doesn't. If you ask someone else, he/she may very well try > to talk you into writing everything as objects and classes. > > Use whatever feels more natural to you.
Thanks for the feedback Jenda. I really think I'll stick with OO for consistency throughout, even if it's just for the simple purpose of having a consistent my $self = shift; ...as the first statement of every subroutine definition. Many of the methods that could-be functions create external objects anyway, and in the event I do need the module to generate an object, I'm already set up for it. Besides... I'm at a stage where I'd rather carry on with Perl BCP and coding, as opposed to changing gears and learning how the Exporter works. Uri's suggestion of the '_' private prefix keeps things well in check. Thanks, Steve
smime.p7s
Description: S/MIME Cryptographic Signature
