The foundation of an object oriented system is the message.
Strong and confident messages requires three elements:
- We must identify the messages we want to send in order to accomplish the task at hand.
- We must identify the roles which correspond to those messages.
- We must ensure the method's logic receives objects which can play those roles.
Roles are names for duck types, simple interfaces that are not tied to any specific class and which are implemented by any object which responds to the right set of messages. Despite the prevalance of duck-typing in Ruby code, there are two pitfalls that users of duck-types often fall into:
- they fail to take the time to determine the kind of duck they really need. That's why up till now we've focused so much on identifying messages and roles: it does little good to embrace duck types when the messages being sent don't match the language of the problem being solved.
- they give up too early. Rather than confidently telling objects that look like a mallard to quack, they fall back on type checks. They check if the object is_a?(Duck), ask it if it will respond_to?(:quack), and constantly check variables to see if they are nil.