Re: Structuring code

How should I structure a series of relatively short functions that each require a handful of parameters, without having to pass all the parameters around? Was I better off before refactoring? Is OO the way to go here?

It would take knowing more specifics to address these, so here is just some basic observation. If there is no requirement that keeps you from using a plain-old run-of-the-mill table to structure your data and your code, then that will suffice (90%+ of the time). Some of the most over-engineered code out there comes from people doing very exotic and fancy things when all they really needed was a simple table with some operations on rows. Tables are simple and everyone can understand it just by looking at it. Moreover, nearly any concievable data structure can be expressed with them, thats why relational databases have been around for so long. (note: this is not a suggestion to use a database, just a comment on structure).

Of course, not everything is amenable to this approach: nested and irregular data structures, a registry, other caveats of course apply. The point is, if all you have is a standardized series of name-value pairs that can be arranged into rows, why not keep it as simple as possible.

### begin_: init
    use strict;
    use warnings;
    use Data::Dumper;

    my  $oDataTable = [
        {
            'type' => 'type1',
            'text2' => 'text-a2',
            'regex' => '[a-z\\d]?',
            'url' => 'http://c',
            'text1' => 'text-a1',
            'dir' => 'a'
        },
        {
            'type' => 'type2',
            'text2' => 'text-b2',
            'regex' => '[a-z\\d]{0,2}',
            'url' => 'http://b',
            'text1' => 'text-b1',
            'dir' => 'b'
        },
        {
            'type' => 'type3',
            'text2' => 'text-c2',
            'regex' => '[a-z\\d]{0,3}',
            'url' => 'http://c',
            'text1' => 'text-c1',
            'dir' => 'c'
        },
    ];

### begin_: process the data
    MungeMyData($oDataTable);
    print Data::Dumper->Dump([$oDataTable], [qw(dataroot)]);

### begin_: the master subroutine
    sub MungeMyData {
        my  $oData  = shift || die"missing data";

        for my $row (@{$oData}){

            if ($row->{type} eq 'type1' ){
                $row->{dir} = uc($row->{dir});
                $row->{text1} = reverse($row->{text1});
                ### munge munge munge ...
            };

            if ($row->{type} eq 'type2' ){
                $row->{dir} = lc($row->{dir});
                $row->{text1} = substr($row->{text1},3);
                ### munge munge munge ...
            };

            ### munge munge munge ...

            if ($row->{type} eq 'type9' ){
                $row->{dir} = lc($row->{dir});
                $row->{text1} = substr($row->{text1},3);
                ### munge munge munge ...
            };
        };

        @{$oData} = sort { $a->{type} cmp  $b->{type}} @{$oData};

        return $oData;
    }###end_sub

### begin_: the end
    1;
__END__
[download]

Comment on Re: Structuring code Download Code

Replies are listed 'Best First'.
Re^2: Structuring code by bobf (Monsignor) on Jan 06, 2005 at 18:02 UTC
Hi scooterm, thanks for the suggestions (and example code). You are correct - there really isn't any reason why I can't use a simple hash lookup table for this data (which is how I have it structured now, although it is a HoH instead), so perhaps I am trying to over-engineer things a bit. The example you gave (based on the OP) essentially follows the same process for each type: `# determine type # process {dir} # process {text1} # munge munge munge...` [download] In my case most of the code blocks are the same, so `process {dir}` is the same code for all types (the only difference between them is the value of `{dir}`, which can be passed as a parameter). There are some instances where the code itself varies, however, which is why I have regexes as part of the data structure. More specifically, I do stuff like this: `my @files = get_filenames( $data{$type}{dir}, $data{$type}{regex} );` [download] which allows me to use the same function to readdir and grep without having a nearly identical copy of it for each `$type`. I guess what it comes down to is that I'm trying to balance minimizing code redundancy with over-generalizing (and therefore over-parameterizing) things. I found myself going in circles about how to design this, so I decided it was time to consult the Monks. Sometimes simple is better than fancy. Thanks for the reality check.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Structuring code
by bobf (Monsignor) on Jan 06, 2005 at 18:02 UTC

Hi scooterm, thanks for the suggestions (and example code). You are correct - there really isn't any reason why I can't use a simple hash lookup table for this data (which is how I have it structured now, although it is a HoH instead), so perhaps I am trying to over-engineer things a bit.

The example you gave (based on the OP) essentially follows the same process for each type:

# determine type
    # process {dir}
    # process {text1}
    # munge munge munge...
[download]

process {dir}

{dir}

my @files = get_filenames( $data{$type}{dir}, $data{$type}{regex} );
[download]

readdir

grep

$type

I guess what it comes down to is that I'm trying to balance minimizing code redundancy with over-generalizing (and therefore over-parameterizing) things. I found myself going in circles about how to design this, so I decided it was time to consult the Monks. Sometimes simple is better than fancy. Thanks for the reality check.

[reply]
[d/l]
[select]