Everything old is new again. The folks who brought us the eXtreme Programming books were, among other things, promoting a set of best practices in software development. One of them, which they termed “Programming by Intention”, was not actually new, but was something that had been a very common coding technique in languages like COBOL and Smalltalk (usually called “top down” programming) years before.
(from the introduction of Programming by Intention)
Programming by Intention appears to be a rediscovery of top down programming where one starts with the top layer and goes down from there.
This was the way that code was written in the days of Pascal and its contemporaries. You started writing the main procedure (it happened to be located at the end of the file, by necessities of the language definition and compiler) and then write a procedure or function, which was then located before the code that called it.
This contrasts with the 'bottom up design' model that OO emphasizes - building the building blocks first, and then building them up from there.
It would be a misconception and misapplication of Programming by Intention to use this to lay a structural framework to the code. Unless the language defines it (a la pascal), it doesn't matter what order the methods are declared in. Readability (and consistency between programmers) is key.
With modern IDEs, one can see the outline of the code quickly and easily. Hitting F3 in eclipse will open up the definition of a method call no matter where it is located in the code. To this extent, the organization of the methods is unimportant. If there is an order use the following guideline:
- Program within the language constraints.
- Program within the language conventions.
- Program within the team's style constraints.
- Program consistently.
If you order top down or bottom up or depth first or breath first or alphabetical, do it. And stick with it.