Are many use statements a code smell?

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

Hello Monks,

In my quest to become a better programmer I've been studying Design Patterns. In one of the programs I've been refactoring has many classes.

use Stu::Account;
use Stu::NameChange;
use Stu::Addresses;
use Stu::Classes;
use Stu::Email;
use Stu::DirInfo;
[download]

The use of so many ‘use’ statement seems like it will come back to haunt me one day. Is this is telling me to use the Factory pattern or at least implement plugins? And if it is, is the use of so many ‘use’ statements always a sign. If not, what are the signs?

Thanks,

rlb3

Updated title as suggested by demerphq.

Comment on Are many use statements a code smell? Download Code

Replies are listed 'Best First'.
Re: Are many use statements a code smell? by demerphq (Chancellor) on Jun 12, 2005 at 13:47 UTC
For those not familiar with the title phrase: CodeSmell Although IMO "Are many use statements a code smell?" might be a better title. And to add an answer, usually when ive had to do this i usually end up putting all the use statements in the root class. So the client says `use Stu;` [download] And all the subclasses are pulled into memory. But i dont have startup time constraints. Its fine for my code to chug a little on startup as it usually runs for hours anyway. YMMV. --- $world=~s/war/peace/g	[reply] [d/l]
Re: Are many use statements a code smell? by borisz (Canon) on Jun 12, 2005 at 13:42 UTC
I do not think there is something wrong with much `use` statements. As long as every of the modules has a independent usage/sense without the others. Otherwise you could refactor it into one module with subclasses. `Stu::AddressBook Stu::AddressBook::Account Stu::AddressBook::Email ...` [download] where `Stu::AddressBook` use the other module parts and your script just start with `use Stu::AddressBook; my $ab = Stu::AddressBook->new;` [download] Boris	[reply] [d/l] [select]
Re^2: Are many use statements a code smell? by crenz (Priest) on Jun 18, 2005 at 00:24 UTC
And Stu::AddressBook could do something like `use Module::Find; useall Stu::AddressBook::Plugins;` [download] which uses Module::Find (caveat: I wrote it ;-)) to find Stu::AddressBook::Plugins::Account, Stu::AddressBook::Plugins::Email, and so on.	[reply] [d/l]
Re: Are many use statements a code smell? by thcsoft (Monk) on Jun 12, 2005 at 13:42 UTC
Is this is telling me to use the Factory pattern or at least implement plugins? not at all! the number of modules you need for an application depends mainly on the application's intentions and purposes. however, you will feel the need for optimizing class designs - but that's another question... just to calm down your concerns (and not for bragging!): in the application that i'm currently working on, the apache-kyrie named 'appstart.pl' uses about 45 classes, two of them allocating around 250kB of static memory. language is a virus from outer space.	[reply]
Re: Are many use statements a code smell? by sh1tn (Priest) on Jun 12, 2005 at 13:41 UTC
Maybe ISA and parent relationship?	[reply]
Re: Are many use statements a code smell? by ruoso (Curate) on Jun 13, 2005 at 10:21 UTC
It wouldn't be a problem if this is an application that will run for a long time and that you know it will use all this classes soon. But if this is, for instance, a CGI application, you may want to switch to requires around your code to avoid the loading of classes you won't need in that run. This will reduce not only the memory use, but also the "boot" time. The question of implementing plugins will not depend on the number of classes (as they might be doing completely different things), but on the number of classes doing the same type of things. Even then, it would depend if you switch on and off some of these classes to make sense (plugin means plug-in and plug-out). daniel	[reply]