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

Hi all,

This is really a design philosophy question more than Perl, but since Perl is what I write in...

I'm a one-man wrecking crew on what began as practice. It's a project that now has 12 modules, and ~70 methods. The goal from the start was to ensure that I could script everything, but put a web GUI on top of it (plugin), so that staff could use it as well.

I feel like the GUI is becoming too large a part of the project. The more code I write, the longer my tests get. I'm putting more core logic into the GUI than I should be. For instance, I've tried to keep everything within an objective programming style, and this is how things would work:

my $client = ISP::User->new( $username );
my $plan   = $client->get_plan( $plan_id );

my $transac = ISP::Transac->create_transac( \%data );

$transac->sanitize();
$transac->renew( \%data, $plan, $quantity );

[download]

...although an example, it's close to reality. However, I've never done programming at the level or scope that this project is becoming, so with the implementation of the GUI, my tests are requiring more 'logic' code built in.

What I'd like to ask the Monks is thus:

What literature (ie: books, whitepapers or docs) and/or feedback would help a budding rookie get a better feel for design strategies? I'm looking for tips on how to identify when a function should become two functions. Is it when a function can't be displayed on a single screen? Is it when it can't be modified to handle any more 'edge cases'?

How can I get better at forseeing my end layout, when all I have is an idea?

Steve

Replies are listed 'Best First'.
Re: Looking for help with design philosophy
by pemungkah (Priest) on Sep 02, 2009 at 00:16 UTC
    The Model-View-Controller (or as @bmf calls it, Data-user-Logic) is a good starting point for a GUI application (and honestly, even or the command line).

    Separate what you're working on and the code that manages that (the model) from the code that puts something on the screeen (the view), and create code that pulls data from the model, does something to it, and either puts it back or shows some of it to the user (the view).

    Being strict about this can make the whole thing lots easier. The controller code turns mostly into code to move data from point A to point B, maybe changing what it's kept in during the process. The view takes very simple sets of data and shows them. The model provides easy ways to get the data from your files/database/network into a data structure that the controller can use.

[reply]

      Thanks pemungkah

      I will look into this as it fits into my original post, but in all honesty, I don't think it's what I'm after.

      REPHRASE: I'm a sole programmer lost in his own project. I need a good book on how to properly fracture/structure/design functions so that they can be re-used, not-forgotten-about and easily-added-to.

      Steve

[reply]
Re: Looking for help with design philosophy
by BrowserUk (Patriarch) on Sep 02, 2009 at 06:31 UTC

    Consider Perl Medic. It is aimed at exactly the kind of problem you are faced with.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      Cheers BrowserUk,

      The book appears to be a great place to start. Thanks!

      Steve

[reply]
Re: Looking for help with design philosophy
by ssandv (Hermit) on Sep 02, 2009 at 19:45 UTC

    I wouldn't place *too* much stock in the old "function/procedure/subroutine should fit on a screen" canard, because its origin predates OOD--and at least in my experience it's a lot more common for OO subroutines to be verbose without a loss of coherence than it is with other methodologies. A procedure should have a coherent idea, and when it starts to become some sort of swiss-army-snippet, it's probably time to split things up or at least make some subprocedures.

    As far as "forseeing the end early" goes, specification is kind of a black art. Part of the reason to do it isn't necessarily that you *can* forsee the end--it gives you a possible end, so that you can then read it and go "oh wait, that's not right at all, it should be this other way". If you don't define things, they tend to be sort of...amorphous as long as they stay in your head, which makes it hard to code them. So I suggest coming up with a semi-complete idea of the end early...not so much to fix the end in place, but to give yourself something concrete to make changes to.

[reply]

Back to Seekers of Perl Wisdom