Sandi Metz - Talk Session: Polly Want a Message

[@jenco116]

Sandi Metz gives the best talks on OOP, and I can't be convinced otherwise.

[@edgeeffect]

"Inject a smarter thing" is the best "slogan" I've heard in ages. It makes more sense of dependency injection than any other explanation I think I've ever heard. So,,, The Viceroy Butterfly is a test-mock! ;)

[@mikemindel3327]

Really enjoyed this video. I've been guilty of writing faux-O and this came at exactly the right time. I was ending up with classes which were more like a collection of functions, rather than anthropomorphic, role-players. It seems like for OO you need to be working with all the affordances and not just cherry-pick the ones you like.

[@ClayShentrup]

She's just the smartest person in the room.

[@gwho]

Clear, easy takeaway: Turn conditionals into polymorphic objects so that you can just send messages, while having the detailed behavior all stuffed at a different level.

[@reidecarvalho]

Source, Subsect and Justifier implement the same interface, "lines". Perhaps using the Decorator Pattern would be more appropriate in the final solution.

[@erikecoologic]

Sandi did it again. 5 stars

[@stephenjames2951]

Odd thing is that with the final version of listing, I think you know more of what it is doing not less.

[@tyo007]

The last part of this video is very important. Sometimes you see something very elegant and you say "I don't know what this thing does.". You don't need to know it, you trust it as long as the test works. The test need to be simple and also elegant that does not break in smallest change as well so it is meaningful If there is no test, then your argument is valid that you can't be sure that it still works OK. You learn what that thing does by looking at the test. if the test doesn't change, the source code change and it still works, no problem then. The main problem is, and happen many times, we skip the test in favor of short dev time..and then it bites us back in the ass later down on the road

[@berniechiu]

Very clear!

[@parijke]

Does anyone know if the slides are anywhere? I would like to investigate the example at ease?

[@elissonmichael2807]

Thanks for sharing this.

[@israzulka]

Master!

[@undefined1150]

Please fix the audio volume, it's too low

[@crc4g2]

Really interesting! Too bad I’m a product manager

[@IlyaDenisov]

It looks like the last step is forgotten - get rid of the classes. All of those "objects" are just procedures - they take arguments and return the result. Which was nicely demonstrated by the introduction of `Clump.lines`. What is the point of classes that only have a constructor and a single method that is going to be called just once? Regarding the `Source`... It was said at 7:17 that OO adds indirection which makes it harder to understand, and yet, instead of just passing "lines" this useless mediator was introduced. You may say "but you would have to call reading method before doing the listing to get lines", but you would call a method anyway - constructor or factory to build an instance. So overall, the idea to refactor was good - but it was left somewhat unfinished.

[@mikemindel3327]

Made me think of "Stop Writing Classes" by Jack Diederich PyCon 2012 kzbin.info/www/bejne/pWrTdq2dfdSlfpI

[@DanHaiduc]

Your comment is absolutely valid for this small example code. But I think the examples were a metaphor for larger apps, where a class does not have just one method, but has many related actions or transformations.

[@allaboutruby7343]

Sandi is GOD!

[@ClayShentrup]

100%

[@CyberPin2001]

Development/Design doesn't need to be so complex! This is serious waffle.

[@ClayShentrup]

The whole point is to make code simple *instead of* complex.

[@MatthewAhrensTech]

"I don't know what anything does" This is a problem if a developer only debugs after the fact when things break. So they have to trace across multiple objects. If they wrote tests first, for each of their individual classes in isolation, then they wouldn't care they don't know what "everything does" together. They can know what each individual piece does and trust that method composition will just work on integration. I love this approach because now I don't need 2^n tests to cover each permutation to find plumbing mistakes. I only need n tests to cover each actor and k tests to cover each factory, and then I can trust that f(g(h(x))) works because how could it not: it is declaritive.