Every now and again, like re-reading a good book, I go out and re-read about various programming ideas -- to refresh my memory, to gain new perspectives, and (again like a good book) to simply enjoy the experience.

So, I was googling about the OO principle of "Tell Don't Ask" and rediscovered this gem from the pragmatic programmers. (as an added bonus, they discuss "The Law of Demeter" too). Enjoy!

PS (for those who feel inclined to forward this to people they work with -- particularly those who are tasked with trying to help their organizations improve their code quality, I have some unsolicited advice):

Before you forward this article on to your colleagues, think about all the other articles you've forwarded to them -- have you been disappointed with what they seemed to learn? If so, I'd like you to consider why...

Despite what you may feel sometimes, its unlikely that its due to a lack of intelligence on their part (IMO if one is smart enough to learn an OO language, one is smart enough to learn OO design), or even their desire to learn. It might be because they need you (or someone like you) there to help them understand how to apply what they've just learned when the decisions are being made (i.e. when they are writing real code).

It may be true that your organization only has a few people such as yourself who understand this stuff, but if you focus your energy on trying to catch other's mistakes after the fact (or trying to account for every design decision they have to make in your standards and architectures), you'll fail to grow new people who understand these things. People need context as well as information to learn properly -- especially when it comes to making judgment calls (which describes all design decisions). So go sit with them, pair with them, mentor them -- not for ten minutes but for an entire task. Let them see what its like to write code like you know how to do it. Blur -- no eliminate! the distinction between learning, delivering, and reviewing... by doing them all at once.

Yes the knowledge spreads more slowly this way (at first), but you'll be a lot happier with the results. And soon you'll have reinforcements who can help others improve their skills too -- they'lll be the very same people that a couple months earlier learned those skills from you.

The biggest benefit for you (apart from being able to work on real systems again) is that you won't be run ragged trying to clean up messes and dumb down the programming process (which never works) in a vain attempt to compensate for a lack of knowledge in your organization.

Who knows, you might even find that you aren't the only one who knows what "Tell, Don't Ask" means anymore.