jonc has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,

I am a beginner programmer, and the use of Strategy(http://www.perl.com/pub/2003/08/07/design2.html) was recommended to make my code better.

The whole idea is a little beyond my knowledge. SO I am just asking for help getting started.

If you could just give me a few hints and point me in the right direction, like Step 1. It would be greatly appreciated!

Thanks!

Here's the portion of the code that is to changed:

            #Dependencies (relations and arguments):
            if ($category_id eq "all") {
                my @lines = split ("\n",$sentblock); ##Split by a newl
+ine
                foreach my $line (@lines) {
                    my @matches;
                    next unless ($line =~ /\b$verbform\b/i); ##Ensure 
+dependency contains searchword
                                ##NEXT LINE IS DIFFERENCE:
                    next unless ($line =~ /subj\w*\(|obj\w*\(|prep\w*\
+(|xcomp\w*\(|agent\w*\(|purpcl\w*\(|conj_and\w*\(/); ##Ensure depende
+ncy only contains desired grammar relations
                    next unless ($line =~ /(\w+)\((\w+)\-\d+\,\s(\w+)\
+-\d+\)/); ##Ensure dependency is a dependency AND get info from it
                    $grammar_relation = $1;
                    $argument1 = $2;
                    $argument2 = $3;
                    
                    next if ($argument1 eq $argument2); ##Ensure 1st a
+nd 2nd argument aren't the same
                    next if ($grammar_relation =~ /xcomp/i and $argume
+nt2 !~ /\b$verbform\b/i); ##Ensure for xcomp the searchword is the 2n
+d argument
                    next if ($argument1 =~ /^\S$/ or $argument2 =~ /^\
+S$/); ##Exclude if argument is only 1 character
  
                    push(@matches, $chapternumber, $sentencenumber, $s
+entence, $grammar_relation, $argument1, $argument2); ##All here, so e
+ither all get pushed or none (no holes in array)
                    push @all_matches, \@matches;
                }
            }
            elsif ($category_id eq "subj") {
                my @lines = split ("\n",$sentblock); ##Split by a newl
+ine
                foreach my $line (@lines) {
                    my @matches;
                    next unless ($line =~ /\b$verbform\b/i); ##Ensure 
+dependency contains searchword
                    next unless ($line =~ /subj\w*\(|agent\w*\(/); ##E
+nsure dependency only contains desired grammar relations
                    next unless ($line =~ /(\w+)\((\w+)\-\d+\,\s(\w+)\
+-\d+\)/); ##Ensure dependency is a dependency AND get info from it
                    $grammar_relation = $1;
                    $argument1 = $2;
                    $argument2 = $3;
                    
                    next if ($argument1 eq $argument2); ##Ensure 1st a
+nd 2nd argument aren't the same
                    next if ($argument1 =~ /^\S$/ or $argument2 =~ /^\
+S$/); ##Exclude if argument is only 1 character
                    
                    push(@matches, $chapternumber, $sentencenumber, $s
+entence, $grammar_relation, $argument1, $argument2);
                    push @all_matches, \@matches;
                }
            }
            ...etc... for a few more elsifs
    
    #To make the if elsif into subroutine: Name:get_all_matches  Pass 
+In: ($sentblock, $verbform, $chapternumber, $sentencenumber, $sentenc
+e) Return:  @allmatches (if needed, return reference)

[download]

Or just tell me if this is not meant for me yet. Or if I should ask this question better. Thanks for your time.

If you want a full look at my code: (http://codereview.stackexchange.com/questions/2911/to-make-a-subroutine-or-not-general-code-tips)

Replies are listed 'Best First'.
Re: How to implement a Design Pattern/ Strategy??
by biohisham (Priest) on Jun 12, 2011 at 15:29 UTC
    I have two comments for you

    I will be considering a subroutine to bypass the repetitive writing of similar code and provide a centralized chunk of code that can be invoked from anywhere within your program, this carries the advantage of making it easier to debug and trace errors, modify & enhance code later and facilitate adding more capabilities centrally that are going to be dynamically extended to the areas in the program invoking the subroutine without having to write too much code or deal with nasty inadvertent typos for instance.

    You can have many subroutines organized by the theme of the activities they will be performing and if necessary they can communicate among themselves, consider this pseudocode: 
    #define functions in themes 
sub dependency_checks{
    #receive arguments and perform the checks 
    #common to the so many if statements
    }

#write your program with the rest of the unique section.

    [download]

    Secondly, how do you intend to use @matches, does ordering matter to you in this case or could you avail of the flexibility that a hash based structure has where you can directly retrieve and have access to values without so much hassle, the link you provided implied that hash-based structures are more flexible.

    From the overview of the concepts presented to you in http://www.perl.com/pub/2003/08/07/design2.html, familiarize yourself with the concepts and consult links such as those in Tutorials->The Uniqueness of hashes.,intro to references but I emphasize that you should go ahead learning Perl in an orderly way without jumping ahead of yourself because new knowledge needs time to solidify and if you have any doubts or questions, seasoned monks will undoubtedly spring to help, best of luck !

    David R. Gergen said "We know that second terms have historically been marred by hubris and by scandal." and I am a two y.o. monk today :D, June,12th, 2011...
[reply]
[d/l]
[select]

      Wow, thanks for all the tips! I was going to make a subroutine, just wasn't sure if I should put everything in it, or only the parts that were **exactly** the same, and then keep the if-elsif structure in the main script. I think I'll stay away from the advanced stuff for now, I think I should learn OO first.

      Regarding @matches, I need all the elements pushed to that array to stick together. They will be outputted together. There will be some duplicate values, but after looking at the code, I think it will still be okay to use a hash...

      My diagnosis: since @matches will be over-written, duplicate key-value pairs in the matches will still be kept in @all_matches. (ie. different sentences mathed have 3 of the exact same elements in @matches, but it shouldn't matter). I will have to try and see

      I need to then sort all the @matches by different criteria ( frequency of matches with the same grammar relation, arg1 and arg2 (which are 3 elements of the 6 in @matches)). Which is why I used @all_matches. So I thought ordering was important. But after reading the Uniqueness of hashes, I may be able to utilize some of those counting duplicate methods. Thanks a lot!

      Just writing this reply sorted some things out in my head...

      Aside: Can I reward good answers on this site?
[reply]
[d/l]
[select]

        "Can I reward good answers on this site?" Yes, once you've accrued a (very little) bit of experience, the Vote Fairy will bring you one or more votes each day. Cast them wisely. See the Voting/Experience System superdoc, a kind of FAQ.

        "Just writing this reply sorted some things out in my head..." You have just (re-)discovered the "Teddy Bear technique." Talk your problems out with a silent but sympathetic listener and the answers will often spring full blown (or nearly so) as if from (someone's) forehead.

        "I think I'll stay away from the advanced stuff for now, I think I should learn OO first." That's probably a matter*1 of taste and learning style...

        ...such as the fact that hashes canNOT contain duplicate keys. This, re your observation "There will be some duplicate values, but after looking at the code, I think it will still be okay to use a hash... "

        And, not just by-the-way, welcome to the Monastery!

        *1 It is also a topic likely to inspire disagreements as vehement as those surrounding such questions as "how many Angels can dance on the head of a pin?" and "Which is the best editor for programming?"
[reply]
        I was going to make a subroutine, just wasn't sure if I should put everything in it, or only the parts that were **exactly** the same...

        Subroutines are useful for avoiding repetition, but the best thing about subroutines is that they let you extract and name a little bit of behavior. Most of my small, single-file programs start out with me declaring main() and then calling a bunch of smaller subroutines from there. I fill them in as I go, and I use their names to describe what they do.

[reply]
[d/l]
Re: How to implement a Design Pattern/ Strategy??
by Anonymous Monk on Jun 12, 2011 at 14:57 UTC
    Well, I haven't looked too closely, but from the short if/else section, you want to start by making functions, like this 
        if ($category_id eq "all") {
        push @all_matches, SomethingAll(...);
    }
    elsif ($category_id eq "subj") {
        push @all_matches, SomethingSubj(...);
    }

    [download]
    which you would later turn into a dispatch table 
    my %dispatch_table = (
   all => \&SomethingAll
   subj => \&SomethingSubj
   _default => \&SomethingDefault
);
...
my $callback = $dispatch_table{$category_id} || $dispatch_table{_defau
+lt};
push @all_matches, $callback->(...);

    [download]
    OO not required. When deciding which function to call requires something more complicated than a simple string comparison (key lookup), you'll benefit more from using object-oriented-programming.

    perl Moose Strategy Design Pattern -> https://secure.wikimedia.org/wikibooks/en/wiki/Computer_Science_Design_Patterns/Strategy#Perl

[reply]
[d/l]
[select]

      Thanks a lot for breaking it down. You make it sound like I could almost do it. I will try implementing your steps.

[reply]

Back to Seekers of Perl Wisdom