in reply to Object Interface and Module Question

First off, you need to slow down. What you have is a wish list, not a module specification. That's not a bad thing -- the wish list marks out where you want to go -- but one should never mistake compiling a wish list for designing code. A good wish list is open-ended, and can easily contain items that won't work together. What's more, wishes don't translate to code very well. They're fuzzy. Either they leave out critical details -- "we want a code optimizer that skips lines that will never execute" (small problem: it's impossible) -- or they specify details that may or may not be necessary -- "... then the hit counter pulls the number of hits from a MySQL database ..."

Programming is the art of thinking clearly, so the best place to start is by defining your terms. For OOP, that means breaking your proposed system down into Entities, Attributes, and Relationships.

In general, it's useful to start with Entities that match things in the system you're trying to model. The fastest way to do that is walk through your wish list and extract all the nouns.

You have a collection of CDs that contain images, so the most natural starting place is to define Collection, CD, and Image Entities, then start assigning Attributes and Relationships. Each CD has an ID number -- attribute. CDs contain Images -- relationship. Each Image has an ID that identifies it uniquely on the CD -- attribute. Each image has binary data that programs can use to paint pixels on the screen -- attribute.

The data itself is formatted, and that looks like a sub-attribute. So it might be worthwhile to create an Image_data class just for that package of information. Then the Image_data object can have a 'format' attribute. You could also give it a 'location' attribute, which would solve your problem with storing images on CD or HD: 

    sub Image_data::location {
        my $O = shift;
        
        my $location = $O->local_storage() || $O->default_storage();
        return ($location);
    }
    
    sub Image_data::local_storage {
    =pod
        returns the path to a file on HD if the image is stored
        locally, and a null string if the image is not stored 
        locally.
    =cut
    }
    
    sub Image_data::default_storage {
    =pod
        combines ID info from the parent Image and CD objects
        to create a filepath for the image on CD.   this routine
        must *always* return a valid filepath.
    =cut
    }

[download]

It's also helpful to examine think about your classes in terms of Roles and Responsibilities. These are really just different ways of looking at Relationships, but Roles and Responsibilities help you assign scope to each class. Ask yourself, "what does this class do?" and "what should this class delegate to somebody else?" and you'll avoid hodge-podge classes that do everything under the sun. If you can't answer either question for a given class, it's a sign that you need to spend some time thinking about that class's scope.

Finally, it's easiest to design programs back-to-front. Decide what output you want, then figure out what input you need to generate that output. Then figure out where those inputs come from, and whether they're output from some other part of the system. Eventually, you'll chase everything back to configuration variables hardwired into the program that let you load further information from the drive.

So -- freeze the wish list for a while, and break your ideas down into Entities, Attributes, and Relationships. That will partition your system, and the module interfaces will flow naturally from there.

Replies are listed 'Best First'.
Re: Re: Object Interface and Module Question
by trs80 (Priest) on Feb 21, 2002 at 22:11 UTC
    Thank you for the detailed reply, despite my horribly assembled post.

    I *really* do want a wish list first.

    My wife has been very patient about out photos and since I am currently not working she thinks this is a good time to get caught up with things around the house, our photos being one of them. I am going to put together something for her as a prototype and then if it is well received and I am pleased with it I will invest more time into the actual requirements vs. wish list at which point your advice will be very helpful.
[reply]

      I'm not knocking wish lists. They are where all software starts. It's just easy to fall down the rabbit hole and keep adding stuff to the wish list until it becomes a snarled mess you can't possibly turn into code.

      Trust me, I'm speaking from experience on this one.. ;-)

      It's also cool to need something ASAFP because The Boss (and a wife definitely counts) wants to see progress. But when speed counts, you need to be very careful about limiting the scope of your work. Nothing can kill a schedule quite the way feature creep can.

      One of the most useful programming axioms I've ever tattooed inside my eyelids is: anything is better than nothing. It sounds like a tautology, but having worked many projects in many settings, I've found that even the ugliest kludge will take you farther and faster than an empty source file and a bunch of grandiose dreams.

      Dreaming is easy, and programming is hard. Therefore, dreaming (usually called: 'planning', 'collecting requirements', 'designing', etc) is a great way to escape the ugly reality of having to write actual code. Not that I'm against planning and design -- far from it -- but if you don't know how to turn what you're doing into code, you're not planning or designing. You're daydreaming. Planning and design are every bit as hard as programming itself, and the only way to tell whether you've fallen into random speculation is to try turning the work into code.

      If you can't even reduce your ideas to a set of nested print() functions: 

          sub do_something {
        print "now we want to do this.\n";
        step_1();
        step_2();
        step_3();
    }
    
    sub step_1 {
        print "  handle this part of the job.\n";
    }

    sub step_2 {
        print "  handle the next part of the job.\n";
    }

    sub step_3 {
        print "  handle some other part of the job.\n";
    }

    do_something();

      [download]
      what you're really contemplating is your navel.

      People fall into the trap of pseudo-planning because they feel overwhelmed. They have a great big wish list, and writing minimal prototypes just seems.. unworthy. So they try to turn the wish list into a map of the final product, and busy-wait themselves into oblivion.

      Don't try to plan software all in one go -- that's not how we build the stuff. Piet Hein, mathematician and all-around genius, wrote little poems called 'grooks' as a hobby. Donald E. Knuth, arguably the world's foremost source of programming wisdom, quotes one of them frequently as the essential model for software development:

      "The road to wisdom?   Well, its plain and simple to express;   Its err, and err, and err again,   but less, and less, and less."

      If you need to be fast, zero in on the smallest number of things your program can possibly get away with doing. Make those work, then start thinking about other things you can add. Get used to iterating through the cycle:

      • make it work
      • make it correct
      • make it fast

      where each 'make it correct' pass gives you enough foundation to keep the next 'make it work' pass from becoming a nightmare. Leave the 'make it fast' stuff for last, because few things screw up a program worse than 'optimizing' it before the part you're tweaking has been set in stone long enough to acquire a few layers of pigeon crap.

      That cycle will zero in on usable, well-built code much faster than top-down design based on speculation instead of code.

[reply]
[d/l]
        The nested print statements give me the look of using some of the test modules on CPAN.

        This is an instance where it is a good idea to write the test plan before writing the code. There are various modules on CPAN which can help here, including Test::Harness and Test::Unit

        Supersearch gives some discussion including Unit Test libraries, opinions

        In my opinion, deferring writing the tests until the end is almost as bad as deferring putting comments in the code until the end. Designing tests focusses the mind on what you are actually trying to achieve.

[reply]

In Section Seekers of Perl Wisdom