In my humble opinion your first question should be "what am I trying to accomplish?" Problem definition goes a long way to proper planning and proper prior planning prevents p*** poor performance.

Module organization should be driven by what makes sense against the backdrop of that answer. More over if you are going to be working with a team of people then the organization of your modules should fit some agreed upon standards

The first thing you have to decide after answering the "what am I trying to accomplish?" question is what you are trying to use the modules for. There are task oriented modules and there are data oriented modules, just to come up with broad categories, and the lines between those two can be very blurred.

Thinking of your MUD application for a second (why does everybody seem to want to write a MUD anyway?) let's come up with a theoretical set of modules:

In my very limited example above you need to assign attributes to each of these "classes" that are in common but distinctive. (Loyalty, movement, hit points, energy points, etc. etc. etc.) and some way to act on those. In a much simpler example: 

package Animal; 

sub new { return bless {},"Animal"; } 
sub speak { };

1; 

package Animal::Dog;
use Animal;
our @ISA = qw/ Animal /;

sub new { return bless {},"Animal::Dog"; } 
sub speak { print "Woof!\n"; } 

1;

package Animal::Cat;
use Animal;
our @ISA= qw/ Animal /;

sub new { reutrn bless {},"Animal::Cat"; } 
sub speak { print "Meow!\n"; } 

1; 

-- ad nauseum --

[download]

We have a parent module Animal with two children modules Dog and Cat. They are both animals, they both "speak" but they are different.

I could have expanded the definition further to include attributes like fur, purring, growling, hissing, tail or no tail, etc. etc. but for simplification I didn't. So when you are designing and organizing your modules think in terms of functionality, commonality as well as disparity.

Another module organization example, this one from Real Life &tm;. 

package Report;

sub new {
    shift;
    my $type= shift; 
    my $self = { 
           format => "html",
           destination => undef 
    };
    my $token = ( 
         $type == 1 ? "::HighLevel" : "::Status" );
    bless $self,"Report" . $token;
} 

sub emit {
    my $self = shift; 
    if { $self->{destination} ) { 
       if ( $self->{format} eq 'html' ) { 
           print $self->{destination} $self->as_html();
       } else { 
           print $self->{destination} $self->as_text();
       }
    } else { 
        if ( $self -> {format} eq 'html' ) { 
           print $self->as_html();
        } else { 
           print $self->as_text(); 
        } 
    } 
} 

sub set_format { 
     my ($self,$format} = @_;
     $self->{format} = $format;
} 

sub set_destination {
     my ($self,$destination) =@_;
     $self->{destination} = $destination;
}

sub generate { 
}

;

package Report::HighLevel;
use Report;
our @ISA=qw/ Report /;

sub generate { 
   my $self = shift;

      # report generation logic here...
} 

sub as_html{
# HTML generation code here. 
}

sub as_text {
# text generation code here. 
}

1;

[download]

What's happening here is I have two types of reports that an application is generating (actually, this is a very condensed version of the real deal) a High Level Report (for management types) and a Status Report (for the troops in the trenches) and depending on how the constructure new is being called for the module Report you get a reference back to a blessed object of either Report::HighLevel or Report::Status. In both cases they have the method generate defined so if I invoke 

my $report1 = new Report(1);  # gets Report::HighLevel
my $report2 = new Report(0);  # gets Report::Status

$report1->generate();
$report2->generate();

[download]
it works the same. That's the beauty of OOP.

Hope my long winded answer is of some help.

Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg

In reply to Re: Module Organization by blue_cowdawg
in thread Module Organization by Dwood

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.