I am having a hard time trying to understand how the message chain was solved. Because she keeps calling where(something).sum(otherthing) inside of Sale.total(something). But I love how she thinks of OO and I love even more that she shares it with us.
From my understanding, it's solved because Sale itself knows "where" and "sum" anyway. It doesn't matter how many dots exist in the chain as long as it doesn't introduce more knowledge(coupling) to Sale.
Because Sale only has to know about itself ("where") and one other object (the one returned by "where", which has a "sum" method - in Rails, this object would be equivalent to an instance of ActiveRecord::Relation). So Foo has gone from knowing about two objects - Sale and the object returned by "where" - to just Sale. This means that, for instance, if the API for the object returned by "where" changed, only Sale would have to be updated.
most people against OO don't truly know OO, and are attacking a strawman or frankenstein procedural OO. They can't see past their limited use cases and how OO provides more flexibility. Just like how graph databases allow you to do everything a table database can, but more... but some people object, saying, why would you need those other features? *facepalm*
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
Awesome talk as always. She's the best!
Always learn something from Sandi.
Brilliant talk some really good points to take away, loved the categories of code smells
Great talk! Tank you so much!
I am having a hard time trying to understand how the message chain was solved. Because she keeps calling where(something).sum(otherthing) inside of Sale.total(something).
But I love how she thinks of OO and I love even more that she shares it with us.
From my understanding, it's solved because Sale itself knows "where" and "sum" anyway. It doesn't matter how many dots exist in the chain as long as it doesn't introduce more knowledge(coupling) to Sale.
Because Sale only has to know about itself ("where") and one other object (the one returned by "where", which has a "sum" method - in Rails, this object would be equivalent to an instance of ActiveRecord::Relation). So Foo has gone from knowing about two objects - Sale and the object returned by "where" - to just Sale. This means that, for instance, if the API for the object returned by "where" changed, only Sale would have to be updated.
I love her, ^^
I feel like Sandi is slowly selling me on OO the more I see of her code, lol
what's the book having code smells and their corresponding curative refactors called?
Refactoring by Martin Fowler
Nice video!!
Great Talk. Anyone knows if we can download her slides anywhere?
anybody got a link to the budgeting reality video that she is talking about at about 25:30 ?
vimeo.com/53276460
most people against OO don't truly know OO, and are attacking a strawman or frankenstein procedural OO.
They can't see past their limited use cases and how OO provides more flexibility.
Just like how graph databases allow you to do everything a table database can, but more... but some people object, saying, why would you need those other features? *facepalm*
whoa! im loving these concepts! abusers Haha thank you!
She had a chance to use penultimate and didn't take it. First time I haven't approved of Sandi Metz. Josh Susser would also disapprove.
Man RailsConf you should really hire a new audio professional
Just in case someone needs the pdf in the slide.
www.industriallogic.com/img/blog/2005/09/smellstorefactorings.pdf