This chapter is from the book
This chapter is from the book
This chapter is from the book
Choosing Message
Sometimes I send a message to choose an implementation, much as a case statement is used in procedural languages. For example, if I am going to display a graphic in one of several ways, I will send a polymorphic message to communicate that a choice will take place at runtime.
public void displayShape(Shape subject, Brush brush) {
brush.display(subject);
}
The message display() chooses the implementation based on the runtime type of the brush. Then I am free to implement a variety of brushes: ScreenBrush, PostscriptBrush, and so on.
Liberal use of choosing messages leads to code with few explicit conditionals. Each choosing message is an invitation to later extension. Each explicit conditional is another point in your program that will require explicit modification in order to modify the behavior of the whole program.
Reading code that uses lots of choosing messages requires skill to learn. One of the costs of choosing messages is that a reader may have to look at several classes before understanding the details of a particular path through the computation. As a writer you can help the reader navigate by giving the methods intention-revealing names. Also, be aware of when a choosing message is overkill. If there is no possible variation in a computation, don’t introduce a method just to provide the possibility of variation.