Imagine an Object's interface is like a kitchen's interface. If a customer at a restaurant would like to order food, he will order the food and communicate with the kitchen through "menu". Menu the kitchen's interface.
The customer knows what it wants, and trust the kitchen to deliver what it wants. The customer does not need to know How the food will be prepared, nor does the customer tell the kitchen how to prepare it.
The kitchen only exposes it's public interface, Menu, and hides it's internal private interface such that customer can not go inside the kitchen and stir the pot.
Domain objects are easy to find but they are not at the design center of your application. Instead, they are a trap for the unwary. If you fixate on domain objects you will tend to coerce behavior into them. Design experts notice domain objects without concentrating on them; they focus not on these objects but on the messages that pass between them. These messages are guides that lead you to discover other objects, ones that are just as necessary but far less obvious.
Ask for "what" instead of telling "how".
You don't send messages because you have objects, you have objects because you send messages.
Context
The things that Trip knows about other objects make up its context…. The context that an object expects has a direct effect on how difficult it is to reuse…. Objects that have a complicated context are hard to use and hard to test; they require complicated setup before they can do anything.
If objects were human and could describe their own relationships, Rather than having the following communication:
- “I know what I want and I know how you do it;”
- “I know what I want and I know what you do”
, This interface communication is much more desired: “I know what I want and I trust you to do your part.”
This blind trust is a keystone of object-oriented design. It allows objects to collab- orate without binding themselves to context and is necessary in any application that expects to grow and change.
Long method chains are problematic because they tie your object to specific public methods of several other objects. This increases the chances that your object may need to change because of changes in a distant object.
The problem with Demeter violations (like customer.bicycle.wheel.rotate) is that they show that code (customer) knows too much about how other code works. It's a manifestation of tight coupling.
The train wrecks of Demeter violations are clues that there are objects whose public interfaces are lacking.
Instead of using the existing public interfaces of the intermediate objects to construct these long chains, you need to figure out what additional public interfaces you need.
Focusing on messages reveals object that might otherwise be overlooked. When messages are trusting and ask for what the sender wants instead of telling the receiver how to behave, objects naturally evolve public interfaces that are flexible and reusable in novel and unexpected ways.