I think some of this discussion has extrapolated from the article and is lacking a concrete code example but some great points all the same.
Not implementing / throwing an error on saving isn't necessarily changing the duck as the implicit interface is entirely defined by the collaborating objects' expectations. Presumably if you implemented as `raise NotImplementedError` then you would not be expecting save to be called making it not a part of the contract. This all depends on the exact details of our imaginary code example though :) On Thursday, 25 February 2016 11:07:49 UTC, Robert Whittaker wrote: > From what I can see here, it looks like this pattern wouldn't fit your > context correctly, Peter. > > > We all fall foul of knowing a pattern and seeing ways in which it might fit > into our codebase when it might not necessarily be the best abstraction. > > > (I know I am guilty of that on a regular basis) > > > Your mention of a "guard `if`" is what sent the alarm bells ringing. It > sounds like your context might be different to this example and that is fine. > > > To me, it sounds like – if you were going to use the Null Object Pattern – > you would want to use it at a higher level where you have a `#basket` method > that responds the way you want to. > > > This brings me nicely onto Sean's comment. > > > Again, I think you might be at too low a level in the code here. > > > You want to be able to re-use the abstraction as much as possible. > > > This is the point that Graham is trying to make. > > > Again it's about having the _right_ abstraction not just _any_ abstraction. > > > As with many things in life, it's difficult without context. > > > On 25 February 2016 at 10:19, Graham Ashton <[email protected]> wrote: > On Thu, 25 Feb 2016, at 09:31 AM, Sean Bamforth wrote: > > > > > 2) If this is a terrible idea, please tell me why this is a terrible idea. > > > > I wouldn’t describe it as terrible, but I think it has issues. > > > > Would you remember to use your new method every time you want to iterate over > `line_items`? Would your team mates? > > > > What’s a “safe line”? This is the first thought I’d have if I started working > on code with a `safe_line_items` method in it. If I was new to the project > I’d waste quite a bit of time trying to find out, as I’d want to make sure I > understood the problem before making a mess of the code. > > > > If my last paragraph seems a bit flippant (because I’ve picked on an example, > rather than a carefully chosen name), it does highlight just how hard it > would be to name your new methods. The correct names are already in use (i.e. > to communicate clearly, the method really ought to be called `line_items`, > and anything else is confusing). > > > > It doesn’t scale. If you adopted this style in your app, you’d have an > explosion of new methods. How would people know whether to call > `a_collection` or `safe_a_collection`? What happens if you want to use this > `safe_*` approach elsewhere (i.e. any place where you might get a `nil` - > it’s not just collections)? I think I’d lose track of what the API is pretty > quickly. > > > > The Null Object pattern solves all these problems (and it’s self > documenting). If you’d like to reduce your conditional statements (which is > well worth it, as you eliminate duplication), why not use it? > > > > Moving away from your question Sean, there are other benefits beyond avoiding > conditional logic. > > > > For example, you don’t need to chase your tail trying to find out where `nil` > came from when you get a `NoMethodError` on `nil`. Writing code that returns > `nil` is a recipe for future pain. > > > > I suspect Sandi gets into that in her talk. It’s online. > > > > https://www.youtube.com/watch?v=9lv2lBq6x4A > > > > “When you came to Ruby, had there not been any syntax for conditionals, it > might have changed how you think about object-oriented code”. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > "North West Ruby User Group (NWRUG)" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To post to this group, send an email to [email protected]. > > Visit this group at https://groups.google.com/group/nwrug-members. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > > > Robert Whittaker > http://purinkle.co.uk > @purinkle -- You received this message because you are subscribed to the Google Groups "North West Ruby User Group (NWRUG)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at https://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/d/optout.
