Re: Module Organization

[blue_cowdawg]

The only question I have, is how should I organize this?

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:

• Characters
  • NPC
  • PC
• Character Classes
  • Mage
  • Fighter
  • Cleric
  • Thief

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

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;

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();

it works the same. That's the beauty of OOP.

Hope my long winded answer is of some help.