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.
In reply to Re: Looking for help with design philosophy
by ssandv
in thread Looking for help with design philosophy
by stevieb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |