Are many use statements a code smell?

[rlb3]

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;

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,

Updated title as suggested by demerphq.

[sh1tn]

Maybe ISA and parent relationship?

[thcsoft]

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.

[borisz]

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
...

where Stu::AddressBook use the other module parts and your script just start with

use Stu::AddressBook;
my $ab = Stu::AddressBook->new;

[crenz]

And Stu::AddressBook could do something like

use Module::Find;

useall Stu::AddressBook::Plugins;

which uses Module::Find (caveat: I wrote it ;-)) to find Stu::AddressBook::Plugins::Account, Stu::AddressBook::Plugins::Email, and so on.

[demerphq]

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;

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.

[ruoso]

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).