Tell Don't Ask (1997)

Alec Sharp, in the recent book Smalltalk by Example

,

points up a very valuable lesson in few words:

— Alec Sharp

That is,

you should endeavor to tell objects

what you want them to do; do not ask them questions about their

state, make a decision, and then tell them what to do.

The problem is that,

as the caller, you should not be making decisions based on the

state of the called object that result in you then changing the

state of the object. The logic you are implementing is probably

the called object’s responsibility, not yours.

For you to make decisions outside the object violates its encapsulation.

referenced object and then calling different methods based on the

results. But that may not be the best way to go about doing it. Tell

the object what you want. Let it figure out how to do it. Think

declaratively instead of procedurally!

It is easier to stay out

of this trap if you start by designing classes based on their

responsibilities, you can then progress naturally to specifying

commands that the class may execute, as opposed to

queries that inform you as to the state of the object.

Just the Data

The main purpose of this exercise is to ensure a correct division of

responsibility that places the right functionality in the right class

without causing excess coupling to other classes.

The biggest danger here is that by asking for data from an object,

you are only getting data. You’re not getting an object—not

in the large sense. Even if the thing you received from a

query is an object structurally (e.g., a String ) it is

no longer an object semantically . It no longer has any association

with its owner object. Just because you got a string whose contents

was “ RED ”, you can’t ask the string what that means. Is it the owners

last name? The color of the car? The current condition of the tachometer?

An object knows these things, data does not.

The fundamental principle of Object Oriented programming is the unification

of methods and data. Splitting this up inappropriately gets you right

back to procedural programming.

Invariants aren’t enough

Every class has invariants—things that must

always be true. Some languages (such as Eiffel ) provide direct support for specifying and checking invariants. Most

languages do not, but that only means that the invariants are not

stated—they still exist. For instance, an iterator has the

invariant that (using Java as an example):

hasMoreElements() == true // implies that: nextElement() // will return a value

In other words, if hasMoreElements() is true, then attempting

to get the next element must succeed, or something is seriously

broken. If you are running multi-threaded code without the proper

synchronization (locking), it may well be that the above invariant doesn’t

hold: some other thread grabbed the last element before you did.

The invariant doesn’t hold; so something is wrong—you have a bug.

According to Design by Contract, as long as your methods

(queries and commands ) can be freely intermixed,

and there is no way to violate the class invariant by doing so, then

you are ok. But while you are maintaining the class invariant, you

may have also dramatically increased the coupling between

the caller and the callee depending on how much state you have exposed.

For instance, suppose you have a container object C .

You could expose iterators for the held objects in this container,

as many of the JDK core routines do,

or you could provide a method that would run some function over

all members in the collections for you. In Java you might declare

this as something like:

public interface Applyable { public void each(Object anObject); } … public class SomeClass { void apply(Applyable); } // Called as: SomeClass foo; … foo.apply( new Applyable() { public void each(Object anObject) { // do what you want to anObject } });

(Forgive the neologic barbarism of “Apply-able”; we’ve found it handy

to name interfaces as “-able”, but English isn’t as cooperative as

one would like).

This is easier to code in languages with function pointers, and even

easier in Perl or Smalltalk where such concepts are built in, but you

should get the idea: “run this function over all contained items, I

don’t care how.”

Law of Demeter

So we’ve decided to expose as little state as we need to in order

to accomplish our goals. Great! Now within our class

can we just starting sending commands

and queries to any other object in the system will-nilly? Well, you could,

but that would be a bad idea, according to the

Law of Demeter . The Law of Demeter tries to restrict class interaction

in order to minimize coupling among classes. (For a good discussion

on this topic, see).

What that means is that the more objects you talk to, the more you run

the risk of getting broken when one of them changes. So not only do

you want to say as little as possible, you don’t want to talk to more

objects than you need to either. In fact, according to the Law of

Demeter for Methods, any method of an object should only call methods

belonging to:

• itself.
• any parameters that were passed in to the method.
• any objects it created.
• any composite objects.

Specifically missing from this list is methods belonging to objects that

were returned from some other call. For example (we’ll use Java syntax

here):

SortedList thingy = someObject.getEmployeeList(); thingy.addElementWithKey(foo.getKey(), foo);

This is what we are trying to prevent. (We also have an example of

Asking instead of Telling in foo.getKey() ).

Direct access of a child like this

extends coupling from the caller farther than it needs to be.

The caller is depending on these facts:

addElementWithKey()
getKey()

Instead, this should be:

someObject.addToThingy(foo);

Now the caller is only depending on the fact that it can add a

foo to thingy , which sounds high level

enough to have been a responsibility, not too dependent on implementation.

The disadvantage, of course, is that you end up writing many small

wrapper methods that do very little but delegate container traversal and

such.

The cost tradeoff is between that inefficiency and

higher class coupling.

The higher the degree of coupling between classes, the higher the odds

that any change you make will break something somewhere else. This

tends to create fragile, brittle code.

Depending on your application, the development and maintenance costs

of high class coupling may

easily swamp run-time inefficiencies in most cases.

Command/Query Separation

Now back to to the ask vs. tell thing. To ask is a query, to tell

is a command. I subscribe to the notion of maintaining these as

separate methods. Why bother?

• It helps to maintain the “Tell, Don’t Ask” principle if you

  think in terms of commands that perform a very specific, well defined action.

• It helps you to think about class invariants if your class

  is primarily command based. (If you are just tossing data out, you probably

  aren’t thinking much in the way of invariants).

• If you can assume that evaluation of a query is free of

  any side effects, then you can:

• use queries from within a debugger without affecting the process under test.
• create built-in, automatic regression tests.
• evaluate class invariants, pre- and post-conditions.

The last, of course, is why Eiffel requires only side-effect free

methods to be called from within an Assertion. But even in C++

or Java, if you want to manually check the state of an object at

some point in the code, you can do so with confidence if you know

the queries you are calling will not cause anything else to change.

References

Sharp, A. “Smalltalk By Example”

McGraw-Hill, 1997.