What you are talking about is in essence Object Oriented Design. Forget all the details, OO is about abstraction. Here is a basic OO program. 

                interface
[MAIN Program] <---------> [DATA Module] <---------> data
                        (abstraction layer)

[download]

This program consists of two logical chunks. MAIN and DATA. MAIN does the stuff and DATA handles the storage/retrevial of the data. All communication between MAIN and its data is via an interface supplied by DATA. An interface is simply a series of methods (subs) that DATA makes available to MAIN. Let's say that this interface consists of two methods: 

get_data_as_array()
set_data_from_array()

[download]

The MAIN program saves or gets its data only via these two methods supplied by DATA. This is called abstraction and the DATA Module is described as an abstraction layer. The abstraction layer serves to separate the program from the storage of its data. How DATA handles getting the data as an array via the get_data_as_array() method or setting the data as an array via the set_data_from_array() method is its own business. DATA may use a flatfile. It might use a RDBMS. MAIN does not need to know. Provided DATA continues to supply these two methods (and they work the same) it is free to do the actual data handling any way it wants. If DATA changes from using a flatfile to a RDBMS then MAIN is *not affected at all* provided the interface is maintained. The abstraction layer provided by the interface is what makes this possible.

So the DATA module abstracts MAIN from the storage of its data making our program into two quasi independent units. The real world benefit is that one team can do MAIN and another DATA. Provided they agree on the interface, they are free to do it any way they want :-)

Most programs have these sort of logical chunks: 

MAIN - to tie it all together
DATA - to handle data storage and retreival
MUNGE - to do fancy stuff to the data
USER_INTERFACE - to make it pretty
WIDGET - to do all the stuff we forgot elsewhere :-)

[download]

So in short you need to sit down, look at the logical chunks, design the interfaces (you can add methods to your hearts content later, you just can't delete or change existing ones) and write a spec.

You also need to apply version control. There is nothing worse than fixing a bug in a chunk of software only to discover you just updated the old version and now have to transfer all the work to the current widget and redo all the testing. There is heaps of stuff on this but that's the exec summary. Hope it helped.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

In reply to Re: hacking a project in groups by tachyon
in thread hacking a project in groups by melguin

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.