Was: Design by contract: predict methods needed, discipline yourself and deal with code that comes to mind

I like the idea of designing by contract a lot (at least, as far as I understand the principal). I believe it means you define intefaces first before you start implementing actual code, right?

However, from my limited experience (3 OOP years now) I usually can't resist the urge to start coding pretty early, for several reasons:

1. because my limited experience has shown me I am unable to predict what methods I will be needing in the interface, so I might as well start coding right away.
2. or because I am simply too impatient to write out the whole interfaces first.
3. or when I do try it, I still wind up implementing bits of code already, because I fear I might forget this or that imporant bit of code, that springs to mind when I am designing the interfaces.

As you see, especially with the last two points, this leads to a very disorderly way of doing things. Tasks get mixed up. I should draw a clear line between designing interfaces and actual coding.

If you, unlike me, are a good/disciplined planner, as intended above, how do you:

1. ...know the majority of methods you will be needing up front so well? Especially if it's components that implement stuff you are not familiar with yet.
2. ...resist the urge to start coding right away?
3. ...deal with code that comes to mind when you are designing the interfaces?

UPDATE:
Thank you for the answers so far. Valuable insights! And... I stand corrected; it seems I misinterpreted the idea of Design By Contract. For clarity, what I actually meant was: "coming up with interface methods before implementing the actual components".

An additional thing that came up in my mind is related to point 1):

1. b) How do you know the majority of components you will be needing. How do you flesh out these things before you start actually coding?

For arguments sake, let's say I'm a novice with the MVC pattern, and I wanted to implement such a component/architecture. A naive approach would be to think of:

• a front controller
• some abstract action controller
• some abstract view

... and be done with it, so to speak.

But, being more familiar with the MVC pattern, I know now that it makes sense to also have:

• a request object
• a router
• a dispatcher
• a response object
• view helpers
• etc..
• etc..

If you map this idea to some completely new component you want to develop, with which you have no experience yet; how do you come up with these sort of additional components without actually coding the thing, and stuble upon the ideas that way? How would you know up front how fine grained some components should be? Is this a matter of disciplining yourself to think it out thoroughly? Or is it a matter of being good at thinking in abstractions?