The distinction between intention and implementation has always been important in software development. It is what allows you to understand a computation first in essence and later, if necessary, in detail. You can use messages to make this distinction by sending a message named after the problem you are solving which in turn sends a message named after how the problem is to be solved.
The first example I saw of this was in Smalltalk. Transliterated, the method that caught my eye was this:
I thought, “Why is this useful? Why not just call
reverse() directly instead of calling the intermediate
highlight() method?” After some thought, though, I realized that while
highlight() didn’t have a computational purpose, it did serve to communicate an intention. Calling code could be written in terms of what problem they were trying to solve, namely highlighting an area of the screen.
Consider introducing an explaining message when you are tempted to comment a single line of code. When I see:
I would rather read:
Even though the implementation of
setLoadedFlag() is trivial. The one-line method is there to communicate.
flags |= LOADED_BIT;
Sometimes the helper methods invoked by explaining messages become valuable points for further extension. It’s nice to get lucky when you can. However, my main purpose in invoking an explaining message is to communicate my intention more clearly.
|This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License|