Alec Sharp, in the recent book Smalltalk by Example
points up a very valuable lesson in few words:
Procedural code gets information then makes decisions.
Object-oriented code tells objects to do things.
— Alec Sharp
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.
Sure, you may say, that’s obvious. I’d never write code
like that. Still, it’s very easy to get lulled into examining some
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):
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
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:
(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.”
You can achieve the same results both ways, either via an
sort of method or via iterators. The choice really comes down to
how much coupling you are willing to have:
To minimize coupling, expose the minimum amount of state necessary.
As shown here,
apply exposes less state than exposing
an iterator does.
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 [APPLETON]).
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
- 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
This is what we are trying to prevent. (We also have an example of
Asking instead of Telling in
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:
- someObject holds employees in a SortedList.
- SortedList’s add method is
- foo’s method to query its key is
Instead, this should be:someObject.addToThingy(foo);
Now the caller is only depending on the fact that it can add a
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
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.
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.
Sharp, A. “Smalltalk By Example”