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

21–30 of 88 posts

Re: Tell, don't ask

#21

Post by gnaritas »

solutionyogi wrote: post #18
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…

Personally, I think this is what 'encapsulation' is about. People have generally thought about 'encapsulation' as guarding the data but I feel that it is about both data + behavior. A quick tip: Any time you check an object's state to decide which method to call on it, you are breaking encapsulation. Call the method on the object and let it figure out what to do based on the state it is in.

> A quick tip: Any time you check an object's state to decide which method to call on it, you are breaking encapsulation.

Unless that object is self. But a good tip none the less.

Re: Tell, don't ask

#22

Post by gnaritas »

0x0 wrote: post #14
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…

To a certain level this is true. However if you hide all branching logic inside OO techniques, following the flow of logic and decisions becomes harder as they are hidden in deeply nested class hierarchies and overridden functions.

There's a saying about good OO code, everything happens somewhere else.

Re: Tell, don't ask

#23

Post by cwp »

gnaritas wrote: post #20
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…

> I'm not saying it's possible to avoid conditionals completely But it is. Smalltalk has no conditional statement, conditionals are implemented via polymorphism on the subclasses True and False (ignoring compiler optimizations).

Yeah, but even in Smalltalk, lots of #ifTrue: messages are a code smell.

Re: Tell, don't ask

#24

Post by gnaritas »

cwp wrote: post #23
gnaritas wrote: post #20

Earlier quoted context omitted.

> I'm not saying it's possible to avoid conditionals completely But it is. Smalltalk has no conditional statement, conditionals are implemented via polymorphism on the subclasses True and False (ignoring compiler optimizations).

Yeah, but even in Smalltalk, lots of #ifTrue: messages are a code smell.

Of course, you can write C in any language if you try hard enough.

Re: Tell, don't ask

#25

Post by briandear »

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…

The better code results if far fewer headaches down the line. Having had to refactor entire apps that have been broken because of incrementally added crap, I vote for good longer code over sloppy shorter code. Of course, this is highly dependent on the situation and application of course.

Re: Tell, don't ask

#27

Post by klochner »

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…

carrying on, why make all user models define a no-op?

   class User
     def post_created(post);  end
   end

   class TwitterUser

Re: Tell, don't ask

#28

Post by mguterl »

klochner wrote: post #27
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…

carrying on, why make all user models define a no-op? class User def post_created(post); end end class TwitterUser

Inheritance is not always the right solution.

Re: Tell, don't ask

#29

Post by ricardobeat »

Disclaimer: not a Ruby user. I'm confused by example 4. Why would you return a message from either of them? Shouldn't messages in general belong to the view?

    {{ user.address || "No address on file" }}
The "not so good" code is essentially this, but inside a wrapper in view code. What if you need different markup for a missing address, you either stuff it into a method or change the method's return value to nil... and what if only street_name is missing, not the whole address? It looks like a big mess to me.

Re: Tell, don't ask

#30

Post by MaxGabriel »

r00k wrote: post #13
MaxGabriel wrote: post #6

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?

I apply this principle to view objects as well. Can you give an example of something you think should be excepted?

I'm still thinking this through, here's what I came up with:

If there's an on/off button to show additional information on the screen, it would seem weird to me to have the button (view) try and display the additional settings. The view has no idea what kind of environment it is in, how does it know if it can display the information without moving other things around. But a controller object managing all the views on the screen does. This also avoids subclassing or adding methods to the view.

Post reply on HN