Tell, don't ask

#1

Post by djacobs » Thu, Jul 19, 2012, 8:10 PM UTC

Tell, don't ask
robots.thoughtbot.com

Re: Tell, don't ask

#2

Post by ninetax » Thu, Jul 19, 2012, 9:00 PM UTC

Awesome! This is think kind of article I love to see on HN.

Re: Tell, don't ask

#3

Post by fusiongyro » Thu, Jul 19, 2012, 9:01 PM UTC

This is a great little refresher. I recently inherited a codebase of about 3500 lines, 2500 of which are in one class. Not OO.

Incidentally, if this article blew your mind or if you're interested in Smalltalk, I can't recommend this book enough:

http://www.lulu.com/shop/andres-valloud/a-mentoring-course-o...

The author has a radical take on OO in Smalltalk and shows that going to absurd lengths to eliminate if-statements (well, ifTrue: et. al., because it's Smalltalk) can lead to both better readability and better performance.

Re: Tell, don't ask

#4

Post by Killswitch » Thu, Jul 19, 2012, 9:44 PM UTC

Wow, short article, but huge impact... I'm gonna start doing this... Makes so much more sense. Thank you.

Re: Tell, don't ask

#5

Post by 0x0 » Thu, Jul 19, 2012, 9:44 PM UTC

Going down this path seems to put your code at risk for dangerous mixing of concerns, in some cases.

Unit-testing the check_for_overheating inside SystemMonitor looks complicated... The "sound_alarms" call inside probably needs to be a reference to a "Speaker.sound_alarms", right? Why should the SystemMonitor be locked to the API of a Speaker? etc.

Re: Tell, don't ask

#6

Post by MaxGabriel » Thu, Jul 19, 2012, 9:46 PM UTC

Cool, I haven't heard of this before; I will think about it. Presumably, an exception would be 'view' type objects in an MVC setup?

Re: Tell, don't ask

#7

Post by tbrownaw » Thu, Jul 19, 2012, 9:46 PM UTC

This principle applies much more broadly than just to programming with objects, for example it's an excellent way to deal with bureaucracies or managers who don't always read their email.

Re: Tell, don't ask

#8

Post by unconed » Thu, Jul 19, 2012, 9:46 PM UTC

Excellent. As a self-taught hacker, I always felt like I was missing something about OO, because it's introduced with an analogy to real world objects, while glossing over the more subtle contracts that programming objects have with each other. Seems like we need a more developed vocabulary to express these things.

Re: Tell, don't ask

#9

Post by jawr » Thu, Jul 19, 2012, 9:48 PM UTC

I liked the first example, but then it felt too preachy; OOP isn't necessarily the correct way to do things.

I really like the clean design of the site though, very fresh imo.

Re: Tell, don't ask

#10

Post by unconed » Thu, Jul 19, 2012, 9:50 PM UTC

0x0 wrote: post #5

Going down this path seems to put your code at risk for dangerous mixing of concerns, in some cases. Unit-testing the check_for_overheating inside SystemMonitor looks complicated... The "sound_alarms" call inside probably needs to be a reference to a "Speaker.sound_alarms", right? Why should the SystemMonitor be locked to the API of a Speaker? etc.

The 'sound_alarms' call looks more like a local method to me, which could invoke the speaker in a loosely coupled fashion.

The point is more about putting the behavior itself in the object. For unit testing, you'd want to move the individual tests into their own classes, letting the SystemMonitor be the glue that calls them and routes responses to the appropriate system.