Talk:Tell, don't ask

added explanations of "Tell, don't ask" principle, might need to simplify my explanation. --Jojo 01:18, 24 July 2008 (UTC)

added a concrete example of "Tell, don't ask" principle --Jojo 02:25, 20 August 2008 (UTC)

Does anyone know of a good paper describing this maxim? --Wal 03:56, 20 August 2008 (UTC)

Doesn't the application of this principal really depend on what you are modeling? To use the example of the Human/Lung, if you have a model where you have many different mammals which each breathe slightly differently, but all have lungs. You could create several Lung subclasses, say HumanLung, SheepLung and HorseLung, along with each of which has an associated mammal class. The implementations of each of the Lung classes may only differ slightly, possibly only providing an implementation of a single method. Now, if you disobey this principle, and have each mammal ask, not tell, and provide it's own breathing implementation then they can all use the standard Lung class. This removes the need for three additional classes and requires the same amount of code. Isn't that the cleaner implementation? ~ Ryan

One paper about this heuristic is at http://www.pragprog.com/articles/tell-dont-ask

Ryan brings up a good point about the tension between this heuristic and removing irrelevant classes. If every creature has its own lung class (none of them share lung classes,) and the lung class only implements one method, then you want to consider using the inline method refactoring.

One of the main ideas of this heuristic is that the interface to an object should not be dependent on its current state. In the ask version of the example given, it is an error to call "breatheSomeAir()" if "getOxygenAmount()" returns > 0, so the interface of a lung without oxygen is different than the interface of a lung with oxygen. This makes dealing with Lung objects problematic. Daniel T.