Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell, don't ask

robots.thoughtbot.com

Post reply on HN
Print view View original

31–40 of 88 posts

Re: Tell, don't ask

#31

Post by lincolnq »

Makes some good points. I can't help but notice, though, that the "good" examples are all longer.

It makes me want to design a programming language that makes good code shorter than bad code...

Re: Tell, don't ask

#33

Post by skybrian »

bluesnowmonkey wrote: post #19

Example 3 adds a nonsense method, EmailUser#send_to_feed. What does that mean? Email users don't have feeds. If we're going to evangelize OO purity, let's do it right. class Post def created user.post_created(self) end def send_to_feed(feed) feed.send(contents) end end class TwitterUser def post_created(post) post.send_to_feed(twitter) end end class EmailUser def post_created(post) # no-op. end end The post merely te…

This is all nonsense anyway. There's no such thing as a TwitterUser or an EmailUser. You just have users, some of whom use Twitter, some use email (and may have multiple addresses), and some use both, and they can edit their settings to add and remove accounts and change notification preferences. So it's really has-a rather than is-a.

Adding unnecessary inheritance is far worse than the original problem.

Re: Tell, don't ask

#34

Post by n72 »

Ick, breaks command/query separation, the other OO rule that along with tell, don't ask I find to be a hallmark of well coded OO systems.

class SystemMonitor def check_for_overheating if temperature > 100 sound_alarms end end end

Re: Tell, don't ask

#35

Post by gav »

The first example isn't a good one. You don't want to have the user class responsible for returning the welcome message.

Re: Tell, don't ask

#36

Post by sukuriant »

This has long been one of my favorite methods of using OO code to my advantage; and is one of the main reasons that my code is OO in the first place.

There are many cases where it's easier/lazier to have if-statements.

Going further, you can take the things learned in this article to make your general purpose code potentially faster, as well. For example, if a set of things that must be performed in order; and sometimes some of those steps are missing, instead of performing a null-check, you can have a default no-op case; that way, instead of:

   if(firstAction != null) firstAction();
   if(secondAction != null) secondAction();
   if(thirdAction != null) thirdAction();
in your inner loop, you can have:

   firstAction();
   secondAction();
   thirdAction();
While whenever firstAction, secondAction, thirdAction are set, you can say:

   firstAction = newFirstAction ?? noop;
   // etc.
All in all, I'm glad this sort of knowledge is getting out there. I'm just grateful for my having really, really good CS teachers back in highschool ( I don't remember my college talking about OO as a way of removing if-statements ).

* Users of Java, of course, will just need to write a NoOp instance of their interface to take advantage of this.

Re: Tell, don't ask

#37

Post by skybrian »

djacobs wrote: post #11

For me, this technique is bigger than objects or encapsulation. It's about reusing existing "branch points" that a language gives you (whether it is polymorphism, method dispatch, namespacing) instead of explicit conditionals at a level higher than the language. My general take is that explicit conditionals in a high-level language are a smell. Sometimes they're necessary, but if you tell yourself that they mostly ar…

It's a poor example of a reasonable technique. Reusing branch points is great. Adding an expensive branch point (inheritance to the User class) to replace a cheap one (if statement) is not a win, particularly when it screws up the model.

Edit: to clarify, by "expensive" I mean expensive in terms of human hours to understand the code, not computer performance. Class hierarchies are much harder to understand than if statements.

Re: Tell, don't ask

#38

Post by ninetax »

rahoulb wrote: post #17
unconed wrote: post #8

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.

I first heard "Tell don't ask" in relation to Smalltalk. If you want a developed vocabulary, Smalltalk is where you find it (and it's been there for thirty-odd years).

What would you recommend? Smalltalk or Pharo?

Re: Tell, don't ask

#39

Post by sukuriant »

skybrian wrote: post #37
djacobs wrote: post #11

For me, this technique is bigger than objects or encapsulation. It's about reusing existing "branch points" that a language gives you (whether it is polymorphism, method dispatch, namespacing) instead of explicit conditionals at a level higher than the language. My general take is that explicit conditionals in a high-level language are a smell. Sometimes they're necessary, but if you tell yourself that they mostly ar…

It's a poor example of a reasonable technique. Reusing branch points is great. Adding an expensive branch point (inheritance to the User class) to replace a cheap one (if statement) is not a win, particularly when it screws up the model. Edit: to clarify, by "expensive" I mean expensive in terms of human hours to understand the code, not computer performance. Class hierarchies are much harder to understand than if st…

The example was small, but this technique can be used to great effect and great ease of reading when you have larger objects and sets of differentiation that you're working with.
Post reply on HN