Just discovered this yesterday myself (don't laugh!):
Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
OO is a tell-don't-ask paradigm. Yes, I know people don't always use it that way, but one of Kay's original concepts was that objects [...] do not ask any questions. They simply tell each other what to do. [...] in original concept for OO communication was half-duplex.
The problem is that, as the caller, you should not be making decisions based on the state of the called object that results 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.
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.
From http://www.pragprog.com/articles/tell-dont-ask and http://blog.objectmentor.com/articles/2010/06/03/tdd-in-clojure
Tags: