Design Patterns by Erich Gamma et al is an excellent book that distills
the experience of a whole bunch of developers and analysts. The whole field of patterns is more or less what you're describing.
Analysis Patterns by Martin Fowler does something similar, but it's mostly for really, really big systems,
like accounting and healthcare systems. Hmm... and Code Complete by Steve McConnell(?) offers some good stuff, too, although
he talks about *modules* as opposed to *objects*.
The only other rule that I know is... practice being wrong frequently. As I'm quite sure you know, there's no trick to understanding
large projects, just experience and finding out what works for you.
People break down projects into smaller bits because projects get too large to keep
in your head all at once. So, experiment with different breakdowns for a system, since there's no one right answer.
Think on paper. If you're visual, draw diagrams. If you're language-oriented, scribble notes. Some people keep Legos
on their desks to build little models. Once you've got it out of your head, show it around to other people, who can sometimes
see flaws. ("Um, why're you subclassing by gender? They've got the same methods, how about making it an attribute?")
System design is not a science, and there are no hard-and-fast procedures. Since I'm a linguistic thinker, I generally start by scribbling down a description of the problem, then start scribbling a list of classes that I think would help to solve it.
Once I get bored with that, I take the objects I've got and scribble some notes indicating how they'll all interact to solve the problem
that the system's supposed to solve, and add and subtract objects as needed. Then I take another look at my list of objects and see if
some need to be broken down further. Then I take a few of the most central, important-seeming objects, and take a crack at developing 'em.
Generally, this suggests some more classes, so I jot them down. Sometime around here I start bugging my coworkers/friends about whether
my design looks vaguely good, or if I'm off the deep end again, and they'll say nice things like, "Stephen, it only needs to accept credit cards.
You didn't need to write a whole new language."
Sorry to ramble... too much tea...
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:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, 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, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||