Thinking in objects instead of in code

Lately I have had a couple of conversations regarding code design. One thing that I seem to find is several people do their “thinking” in code. They typically will sit down, start coding up a prototype, get it written from beginning to end, one step at a time. They tend to think in a linear, or at least procedural fashion. Once they have their first run of code, they will reduce it down into objects, frameworks, etc. This is quite different than the way that I tend to code. I am not suggesting that my way is better, it is, however, interesting to look at the differences. Typically I will try to reduce my problem into a “black-box” meaning I will try to find the absolute inputs, and the absolute outputs. Once I have that data path, I will then make an interface that offers that data path. I then make a pass through the interface, filling in high level functionality. I will then make a second pass, filling in lower level functionality, and so on, until all the functionality is present. It looks very much like developing a fractal. I do this because I don’t think about how the code will look so much as how the interfaces will look. This tends to drive me to visualize how the objects will look. I can then see what patterns will fit a given implementation quickly. I can also see if my design is not fitting the problem, and avoid or change things before I spend all my time implementing the bottom level details.

One disadvantage I do have though is I will tend to have to take slightly more time to develop my solution since it’s not usable until it is complete. Typically a “code thinker” will have a functional first run, even if it’s not elegant. However, in their “reduction phase” they may have to restructure the code significantly, with a rippling effect. This tends to end up causing their final product to take more time to develop than starting from a high level and filling in. I also tend to run into more language limitations since I am going from abstract towards concrete, and sometimes the language will not allow a process that I require. Since I don’t fill in the details until later, I may not discover this until it’s too late. This is very rare, but it does happen. When it does, I may have to rework a few bits of my design to compensate for the languages limit, but even these changes seem to be fairly isolated.

So, given these two different ways of coding, which works better? They both do. They seem to be fundamental ways that our brains work. Being aware of how others work can be beneficial for one’s self, even if it’s not practical to implement the other’s solutions. In the (in)famous words of Larry Wall, “there’s more than one way to do it.”


One Response to “Thinking in objects instead of in code”

  1. Peter Birch Says:

    I find that I do a little bit of both. In general I think in code but when I start a project I usually start with the class header files and start creating classes and filling in the public interface. I then start with a small test app where I can exercise the classes and then start filling in the code for the classes. Very iterative from here on out.