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

71–80 of 88 posts

Re: Tell, don't ask

#71

Post by gnaritas »

ori_b wrote: post #70
gnaritas wrote: post #50

Earlier quoted context omitted.

You have to change how you read code. Stop worrying about implementation details and see the objects API, and stop digging into every method, you don't need to see the implementation all the time. Step back, look at the classes and the messages between them and ignore the implementation whenever possible. When you understand how the parts work together, then you tend to know which part is broken for any given bug, an…

But they're not simple. The complexity is still there, it's just distributed and difficult to trace. I much prefer the functional way of doing things. The complexity is still minimized, but I can see where things are coming from, and how data is composed. While it's harder to add "cases" to types in the functional style, I find myself wanting to add functions over types far more often, and therefore, I find that it w…

Of course do what works for you. But distributed is the wrong word in a sense, the complexity is broken down into simpler parts that aren't complex, that's the point. If you're unwilling to adapt your reading style, then you won't see the benefits because your thought process isn't congruent with the style.

You clearly prioritize data over behavior, so naturally functional code fits your thought process better, but your though process is one among many. OO works well when your thoughts are behavior centric rather than data centric.

Functional and OO actually go very well together.

Re: Tell, don't ask

#72

Post by LukeShu »

lincolnq wrote: post #31

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...

With the exception of example 3 (which is possibly a bad example, see the discussion above), this is because of how much code is necessary to tell what's going on, rather than an increase in code size.

Example 1: 5->1: It did get shorter.

Example 2: 5->8: One of the lines is showing a line calling the check_for_overheating method, which wasn't shown in the first example. The other two are declaring the SystemMonitor class, which was declared "off-screen" before.

Example 4: 7->13: Five lines for declaring and defining User.address, which was off-screen before. So it did get a line longer.

Re: Tell, don't ask

#73

Post by malyk »

halogen64 wrote: post #61
klochner wrote: post #27

Earlier quoted context omitted.

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

A better solution would be to just use Observers. One for email, one for twitter. The user shouldn't care about how to talk with these services.

Observers are one of the worst possible solutions because they lie outside the purview of, well, everything in the system. You don't ever see them in the code. You don't know they are there. They are pieces of unicorn code that have side effects that you won't know about or see because they aren't "in the code". Horrible solution.

Code should be simple and easy to understand. Observers add significant complexity and make your code vulnerable to unnecessary bugs because the code that acts on your objects is invisible to the normal control flow of the program and those who write or maintain it.

Re: Tell, don't ask

#74

Post by sukuriant »

cgmorton wrote: post #65
sukuriant wrote: post #57

Earlier quoted context omitted.

I may expand on this later; but, whenever you're going to a new code-base, you're going to have to learn the various idioms that are at work in that code base. This is especially true when you're working with some more complicated languages where no one uses the whole set of it (see: C++). When I'm writing my code, I personally find that being able to trust what my code is doing to be more readable. In the case I wro…

It's an interesting point about the speed. In this case, since it's just a function pointer, there's no polymorphic overhead, so avoiding branches is a no-brainer. On the other hand, if you were actually extending a class to make a DoNothingClass version, then the overhead of dynamic binding plus the function call would make it somewhat slower (branch prediction on a NULL comparison will cost at most 5 clock cycles i…

"will cost at most 5 clock cycles in a single-thread pipeline"

Being a little pedantic here: you can't safely say this part without knowing which kind of branch predictions the processor uses; and, more importantly, how deep the branch prediction can go. There are some processors that will branch predict once ... and then again, and again and again. The first one they get wrong, they have to roll back to that first one. But then, you're right. The more times that single method is called, depending on the implementation of branch prediction, the more often it's going to be right, and so as long as those values aren't changing often (I don't see why they would in the case we're trying to suggest), it may eventually fade into nothing.

Needs moar testing!

Re: Tell, don't ask

#77

Post by rahoulb »

ninetax wrote: post #38
rahoulb wrote: post #17

Earlier quoted context omitted.

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?

I'd recommend "The Art and Science of Smalltalk" by Simon Lewis.

Because it's so old, Smalltalk does things very differently to other development environments.

The GUI is strange by today's standards (Smalltalk was why Xerox developed the GUI - you can see how much extra work Apple did to make the windows/icons/menus that we use today).

And it uses an image (which is sort of like developing in a VM, and then copying that VM to another machine to deploy).

So diving straight into a Smalltalk may leave you a bit lost - whereas the book is quite a good primer on OOP in general and where those OO patterns came from (whether Squeak, Pharo, GNU or one of the big expensive implementations).

Re: Tell, don't ask

#78

Post by regularfry »

dekz wrote: post #46
mguterl wrote: post #28

Earlier quoted context omitted.

Inheritance is not always the right solution.

Especially when the examples are written in a language which has mixins as core functionality.

Mixins are inheritance. When people say "prefer composition over inheritance," they don't mean mixins.

Re: Tell, don't ask

#79

Post by edoloughlin »

I'm not trying to be elitist or superior, but I can't understand why this has spent such a long time on the front page. Shouldn't the content of the article be considered pretty basic knowledge at this stage of OO? Deferring implementation specifics using polymorphism was one of the first things I learned about OO when I was introduced to it (via C++) around 1992. It was definitely 'aha' worthy then, when the vast majority of commercial development was procedural, but these days? Shouldn't it be considered a basic tool in most devs' repertoire?

Re: Tell, don't ask

#80

Post by djacobs »

edoloughlin wrote: post #79

I'm not trying to be elitist or superior, but I can't understand why this has spent such a long time on the front page. Shouldn't the content of the article be considered pretty basic knowledge at this stage of OO? Deferring implementation specifics using polymorphism was one of the first things I learned about OO when I was introduced to it (via C++) around 1992. It was definitely 'aha' worthy then, when the vast ma…

It should be, but I can assure you that it's not. Also, I think this has much less to do with OO than with conditionals at large.
Post reply on HN