This chapter is from the book
This chapter is from the book
This chapter is from the book
Explaining Message
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:
highlight(Rectangle area) {
reverse(area);
}
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:
flags|= LOADED_BIT; // Set the loaded bit
I would rather read:
setLoadedFlag();
Even though the implementation of setLoadedFlag() is trivial. The one-line method is there to communicate.
void setLoadedFlag() {
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.