Object-oriented programmers: what is your process when you're physically coding?

What language are you coding in? In .net there are interfaces, that I have found to be very useful. I don;t remember whether Java has anything similar. With interfaces you can avoid the need for stubbed code.

I do find myself working on several things at once. One driving concern is to be able to test as I go along. This frequently leads to initial concentration on auxiliary modules.

@LostInParadise I’m mostly writing in Objective-C, but I would think the problem is universal to any object oriented language. It’s like the same problem with writing a choose-your-own adventure book, whenever the story branches, do you continue down the rabbit-hole of one story path, or work out each branch, before delving deeper in?

I guess what’s frustrating is that I get a flurry of ideas, and because I’m so prone to loosing my train of thought, I feel obligated to get it all down, lest I forget. Thanks for taking the time to answer.

I always write “documentation” first. I start with a README file which outlines the way I think the code should go. When I find myself referring to functions (I’m mostly a functional programmer, but this should also work in OO) I’ve not yet coded I write them up in the file with a description of what they should do and what calls them, etc. If I don’t do this I will get lost.
Also, when I’m writing code, I write comments first telling me what I meant to do, then code between the comments. About half these comments wind up staying with the finished code as documentation (except that they all change many times during the programming process- the comments at the end are never actually the same as when I started).
When I program I tend to try to work from the “branches” (functions / methods that are called but don’t call other things) inwards toward the “trunk” (i.e. main() or other parts of the code that need to call things) which allows me to test the outer functions thoroughly before calling them from real code.

Hmm, good question!

I think it depends on how complicated the unwritten methods are, and what I feel like doing. I tend to do what’s easiest for me.

Usually, and when the unwritten methods are fairly complex, I tend to make up explanatory method names and use them as if they existed:

Like (not exactly, but since I have no specifics):
pOtherObject.DoAllNeededLogicForWhenXHappens();

If it’s something simple, though, I may just go implement it and come back.

Flowchart to documentation outline to primary code, then finish wih the subroutines

I tend to stick with what I’m doing for exactly the “flow” reason you describe.

One thing that’s worked well for me is to keep a list handy that I jot down those little “to-do” items on immediately when they become needed. This can be a text file, a sticky note, or any of the online to-do list managers that are available.

So I’d stick with the object I’m in right now, because that’s fresh in my mind and I have everything mapped out, but jot down the new method name and either key attributes or an example call to that method/function so I can refer to it later. Usually if I know the name, and the key attributes, I can write the rest without referring (mentally) back to the current object.

Once I’m done with what I’m on and wondering what’s next, that list is populated with all the dependencies and I find it helps me move through the project more smoothly as well. Less wasted time looking for the holes that inevitably occur with any process.