in reply to Coming up with code design
Back when I was studying stuctured program design (and promptly forgot most of it and had to relearn it), I remember my instructor explaing that all programs had four steps:
- Initialization
- Input
- Calculation
- Output
Admittedly, that's a bit simplistic and I suspect that he was only familiar with procedural programming (as opposed to functional, OO, and logical). While I don't necessarily design my programs into four sections, they often break down that way.
What I usually do is start with the output. What do I want my end result to be? From that, I can determine what data I need to capture. Then, I go to the input section and figure out my data sources. With this, I have my beginning and end data and I find it relatively easy to work out the data flow (well, usually).
The data flow, to me, is the 'calculation' part. Frankly, I don't even worry about my data structures until I have some idea of what those calculations are. With that, I can often identify common elements to factor out. Once I know those, I design data structures to fit them.
I can't say that I follow this process religiously (ooh, I'm a bad monk), but what I prefer to do is something similar to this node. Also, Warnier-Orr design is something that I've enjoyed, though it often breaks down with object-oriented programming.
Cheers,
Ovid
Vote for paco!
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
|
---|