note
Discipulus
Hello i'm less or more in the same situation. The moment when you pass from standalone scripts to modules is crucial (from my point of view) moment that tells the scriptor from the progammer.<P>
You abstracts functionalities (possibly grouping them on affinities) from your main script that become a bare bone sketch of your desired behaviour of the application.<P>
So if your application is <C>ZXappz</C> and you need to log and also use a database connection to read data you'll probably need a <C>ZXappz::Logger</C> and a <C>ZXappz::Database</C> modules. maybe the main <C>ZXappz.pm</C> just loads these two modules. Is <C>ZXappz::Logger</C> that uses
<C>log4perl</C> and <C>ZXappz::Database</C> will load <C>DBI</C><P>
This in the simplest case ie when you just group functionalities into modules for a logical separation. The application can be one or more scripts that use such functionalities (subroutines exported by your modules) to do the work.<P>
In this perpective you gained in readability and maintenence. But there is a better gain: you can document and test your software in a just one place: the module file. Better: you can embrass the "test driven" develop method that will save your time in the long run. You imagine a functionality let's say you want to write to alocal file whe the database is offline. Ok, first you choose a meaningful name like
<C>db_fallback_write</C> and you imediatly spot <C>ZXappz::Database</C> as the right place to put it. Then, before coding the subroutine, you wite the POD documentation in the module for the functionality. you describe it as you wont it. Then you write an initial test (a <C>.t</C> file in <C>t/</C> dir of the <C>ZXappz::Database</C> distribution) for <C>db_fallback_write</C> let'say return the name of the file written on success and 0 on failure. only now you start to code the sub <C>db_fallback_write</C> in the <C>ZXappz/Database.pm</C> file. You are defining an interface for your software: the <C>db_fallback_write</C> functionality want some parameters and returns something. it does it's work as described in the POD.<P>
<C>db_fallback_write</C> may needs to chose a filename based on the day of the week. This is something private to the sub implementation: the final user of <C>db_fallback_write</C> (you or your script) does not need to know how the filename is composed. So in the <C>ZXappz/Database.pm</C> you can have a <C>choose_filename</C> sub (or as frequently happen a name starting with underscore <C>_choose_filename</C> ). <C>choose_filename</C> can have it's own tests but not POD documentation because it is not part of the interface but only of the implementation.<P>
i hope i gave you the idea. wiser monks can add and specify about the matter. In my homenode you can search for the string <C>About new modules</C> to see a bounch of links on the subject.<P>
HtH<P>
L*<P>
<div class="pmsig"><div class="pmsig-174111">
There are no rules, there are no thumbs..<BR>
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
</div></div><!-- Wiki2Monks {"version":1.1415} -->
1154914
1154914