Well we have to be careful about terminology here, so why do we start out making a few definitions.

A module _could_ be defined as a perl code file with a .pm extension that contains one or more package declarations

And a package _could_ be defined as a concept where code, declarations, subroutines, methods and documentation relating to a specific implementation are collected

Note that if we use these definitions, a package can span several modules (files with .pm extensions)

So lets consider just single .pm file that completely contains one package (declared with the package keyword)

So for package Foo::Bar, I need look for a file Foo/Bar.pm, which starts (in general) with the declaration

package Foo::Bar;
[download]

With that in place, you question about use and require, use is (generally) the same as

BEGIN {require Foo::Bar; Foo::Bar->import();}
[download]

In general, you'll make use of require (no pun) when dynamically pulling in modules i.e. you dont know until runtime which module is required (again no pun) until after compilation.

As for @_, I use this, but I am using Params::Validate a lot now and passing hashes so I have named argument lists e.g.

my $baz = Foo::Bar->new(easy      => 'to',
                        see       => 'whats',
                        happening => 'here');
[download]

which means no more remembering the positional significance of arguments - its almost self documenting

For data 'from your script' to the module, try not to call out to a scripts data from a module - it reduces the reusability of that module, as every script must be written with that data in place if it wants to use the services of the module.

So dont do this

package Dark::Madness;

my $inner_demon = $main::higher_demon;
...
1;
[download]

Try to pass data back and forth through the interface - e.g.

$foobar->set_widget(param1 => value1,
                     param2 => value2,
                     );

$foobar->use_widget();

my $widget_dreams = $foobar->get_dreams(style => 'psychotic');
[download]

There are lots of consideration on the use of @EXPORT, @EXPORT_OK and %EXPORT_TAGS you should read up on, but basically try to use these as little as possible - they can be useful, but some people get upset when a symbol they have named gets clobbered by a symbol of the same name that is rudely exported by a modules @EXPORT list.