Design by contract: predict methods needed, discipline yourself and deal with code that comes to min
- by fireeyedboy
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:
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.
or because I am simply too impatient to write out the whole interfaces first.
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 thing. 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:
...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.
...keep yourself from resisting the urge to start coding right away?
...deal with code that comes to mind when you are designing the intefaces?
