Re: How to implement a Design Pattern/ Strategy??

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

Comment on Re: How to implement a Design Pattern/ Strategy?? Select or Download Code

Replies are listed 'Best First'.
Re^2: How to implement a Design Pattern/ Strategy?? by jonc (Beadle) on Jun 12, 2011 at 17:51 UTC
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]
Re^3: How to implement a Design Pattern/ Strategy?? by ww (Archbishop) on Jun 12, 2011 at 19:23 UTC
"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]
Re^3: How to implement a Design Pattern/ Strategy?? by chromatic (Archbishop) on Jun 13, 2011 at 02:54 UTC
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]


Syntactic Confectionery Delight
	PerlMonks