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

Hi Monks, I need a little help designing a tool. The purpose of the tool is to test some incoming outgoing ports in preparation for a software application that we install. The way i am designing this tool is that i have a system script called system.pl that initially prompts the user to enter the following: IP, MASK, DNS, NTP, GW etc It then saves all this information in a log file. Afterwards it checks for instance if the given hostname resolves to the given IP. To achieve this there is another script called dns.pl. Similary every function has a script named after it. Taking the example of dns.pl.
sub getIP{ my $result = $resolver->query($_[0]); return $result; }
All variables are already defined as this is just an example. What i want a little help with is that should i return objects from these perl scripts or do the processing for instance and get all A records and return strings or arrays ? What would be a good approach ?

Replies are listed 'Best First'.
Re: Code Design Help
by thomas895 (Deacon) on May 24, 2012 at 03:57 UTC

    There is no right or wrong answer to this -- use what will work best for you. Keep efficiency in mind too, don't do any unnecessary things that only slow the program down.
    Since I don't know what $resolver is or what else must be done to the result, all I can say is "that looks fine".

    ~Thomas~
    I believe that the source code to life is written in Perl :-)
Re: Code Design Help
by locked_user sundialsvc4 (Abbot) on May 24, 2012 at 14:05 UTC

    Sometimes in a situation like this it works well if the individually-called scripts are “stub” routines that use a common package, perhaps employing the contents of that package as an object (because, when you do so, you now have lumped code-and-data conveniently together).

    The idea here is that, even though you have several scripts being called by your command-files or what not, all of the related code is actually in one place and not repeated.

    I like to define subroutines (or properties, as the case may be...) so that there is no “just one right-way to call it.”   In other words, I would instantiate the object and give it a method that “magically” returns the IP on-request.   When you call it (because that is what you want to know), the code does whatever it has to do at that time ... or else it realizes that it can’t do so and it dies with a meaningful message.   I don’t like to see routines that, “well, they work properly, if you have done this-and-that first, otherwise it does weird things.”   (I call the latter “genie in a bottle” routines, from the very bad pop song that was around a few years ago:   “... you gotta rub me the right way.”)

Re: Code Design Help
by jack123 (Acolyte) on May 24, 2012 at 06:08 UTC
    In this case, I would have choose objects since the data may keep changing and i also want the data to be secure. So. i'll go with objects. But when you say the parameters in objects then obviously hash or array will be used for that. I'm using object just to make the code to work faster and use only required data not to run unnecessarily the whole code. Now, it's on you which approach suits you better. Go ahead with a practical demonstration too and use timer function to check the time consuming.