Dec 01, 2010
I am currently reading this book. Many excellent Java programmers think the tell, don't ask approach is the best way to program. I can see their point, but, having dabbled in functional programming, I am amused at what is considered 'good practice' in different contexts.
In the functional programming world, functions (should) avoid side-effects unless all other options have been exhausted. Thus, it is good practice to combine many 'getter' methods together, operating on lists of lists to derive new values or get something done.
I suppose the key is be consistent: either avoid side-effects, mainly ask and have one function that combines everything together into a process/task (doing something) or follow the 'tell, don't ask' style for separation/decoupling. At the end of the day, it comes down to roles/responsibilities. An object/function/process/piece of code should be expected to either provide information or alter it in any way it sees fit. In fact, good style is probably knowing when to expose data and not. Easily done when each class is tagged as 'read' xor 'write' for a given task.
One way of promoting this is defaulting to immutable, ala Scala (val, collections etc.)