I love Sandi Metz's talks and writings, when I was new to Ruby she really helped me step up my code, and this talk is great. I know I'll learn something really important whenever I see her in a conference, and then wonder how I never learnt about that before :)
Wow, this was such an informative and entertaining talk. My brain could barely keep up! I prefer to work in a functional style these days, but this was still really helpful, and much better than the popular narrative of "prefer composition over inheritance", since it's backed up by solid examples and discussion rather than just being a flat assertion.
The question I then have is what is the major difference between functional and object oriented programming? Both depend on composition, the null object pattern become the maybe type and so on.
Oh, and functional platforms such as BEAM (Elixir, Erlang etc) are heavily dependent on the concept of message passing. Come to think of it, it's important for Haskell as well.
To honestly answer this, you have to go explore functional programming. Describing an orange to you does not let you understand the experience of eating an orange. If you truly care to understand the difference: go try it. The composition is different, programming with monads (null object pattern) is different, and so on.
Sandi Metz I got so inspired by this talk I decided read her book and then got inspired again this time to write an article about her book medium.com/@mithi/review-sandi-metz-s-poodr-ch-1-4-wip-d4daac417665
The null object pattern is the least useful pattern I know. Do yourself a favor and read the "criticism" section of the Wikipedia article. en.wikipedia.org/wiki/Null_object_pattern The Animal example nicely illustrates the kind of problems this creates. Presumably Animal has some properties and methods beyond just the name, right? How does MissingAnimal respond to various messages intended for actual Animal instances? How many legs does it have? zero? nil? does it have fur? true, false, nil? what species does it belong to? MissingSpecies? nil?? Think about it: your MissingAnimal needs to have a nonsense answer for every question you could ask about an Animal. The null object pattern creates more problems than it solves.
Sure, but it's a contrived example. A better one might be loggedInUser where the null class is AnonymousUser. Like she said, if null really is nothing just throw it away but anonymousUser is a concrete idea. There's no silver bullet, programming defensively is boring but this pattern is useful *sometimes*
Sandi Metz is one of the best, if not the best, educators on object oriented design. Amazing stuff.
This is one of the best talks i've seen in a long time!
I love Sandi Metz's talks and writings, when I was new to Ruby she really helped me step up my code, and this talk is great. I know I'll learn something really important whenever I see her in a conference, and then wonder how I never learnt about that before :)
this is on my list of the greatest ruby talks of all time
A perfect example of the strategy pattern. The mother of all patterns!
this gives me the chills everytime I watch it
Composition over inheritance is great as always :)
Wow, this was such an informative and entertaining talk. My brain could barely keep up! I prefer to work in a functional style these days, but this was still really helpful, and much better than the popular narrative of "prefer composition over inheritance", since it's backed up by solid examples and discussion rather than just being a flat assertion.
Brilliant. Metz is just so damn good.
wow ... this is great!!!!!!!!
Awesome! It blasts my mind : the invention of nothing! ;) Thanks
How is this video different than the other one with more views on Confreaks channel?
I really enjoyed this talk. Thank you!!
How to implement smalltalk conditionals in other languages?
great talk!
Superb
does someone knows about some kata i can use to practice this?
This really makes me wonder when inheritance is the right tool of choice - and abstract base classes in general.
Almost never, in my opinionated view :) Compose!
The question I then have is what is the major difference between functional and object oriented programming? Both depend on composition, the null object pattern become the maybe type and so on.
Oh, and functional platforms such as BEAM (Elixir, Erlang etc) are heavily dependent on the concept of message passing. Come to think of it, it's important for Haskell as well.
To honestly answer this, you have to go explore functional programming. Describing an orange to you does not let you understand the experience of eating an orange. If you truly care to understand the difference: go try it. The composition is different, programming with monads (null object pattern) is different, and so on.
This is the Maybe monad!
At this time Object-oriented absolutely blew my mind.
This is a special occasion. I'll have a cigarette.
Horrible way to celebrate. Try a cigar ;)
Sandi Metz I got so inspired by this talk I decided read her book and then got inspired again this time to write an article about her book medium.com/@mithi/review-sandi-metz-s-poodr-ch-1-4-wip-d4daac417665
Well my mind is blown lol
so painfully obvious if you're coming from functional programming :D
The null object pattern is the least useful pattern I know. Do yourself a favor and read the "criticism" section of the Wikipedia article.
en.wikipedia.org/wiki/Null_object_pattern
The Animal example nicely illustrates the kind of problems this creates. Presumably Animal has some properties and methods beyond just the name, right? How does MissingAnimal respond to various messages intended for actual Animal instances?
How many legs does it have? zero? nil? does it have fur? true, false, nil? what species does it belong to? MissingSpecies? nil??
Think about it: your MissingAnimal needs to have a nonsense answer for every question you could ask about an Animal.
The null object pattern creates more problems than it solves.
Sure, but it's a contrived example. A better one might be loggedInUser where the null class is AnonymousUser. Like she said, if null really is nothing just throw it away but anonymousUser is a concrete idea.
There's no silver bullet, programming defensively is boring but this pattern is useful *sometimes*