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.
Am I correct in assuming that this rule only refers to when your asking for data to complete your logic? Otherwise following this principle would remove the need for getters, since you shouldn't be asking for data anyway. This would have some drastic implications, for example consider any list/pair/array/set class, we commonly use getters with these kinds of classes, surely we shouldn't have to tell our list class what we want it to do, should we? ~ Ben
added a quote from http://www.c2.com/cgi/wiki?TellDontAsk that helped clarify things for me --Benjamin Gibson
Just wondering if this has any implications towards the design by contract idea. Hmmmm User: Nelson Shaw
