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 }
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.
In reply to Re: Object Interface and Module Question
by mstone
in thread Object Interface and Module Question
by trs80
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |