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