Good morning, everyone. Sorry if my response is delayed; I only check my emails once a day.
Graham, thank you very much for your comments on the article. I'll have another read through later to make sure, but what you are saying makes sense. It's easy to get lost in the weeds when you are so close. I also agree with you in terms of `MissingBasket#save`. If this method was being called somewhere in my codebase then I would usually expect that the flow of the application had become defective. As an implementation of the Null Object Pattern, `MissingBasket` should be just doing the bare minimum it needs to get by. When it comes to inheriting, I would be more likely to create a `Basketable` module/concern in this case. I don't think that `MissingBasket` is actually a `Basket`. Because of my reluctancy to couple my code to Rails, I would also be loathe to inherit from `ActiveRecord::Base` too. It seems unnecessary. I'm glad we've opened up a dialogue. I feel like it's something that has been missing from our community. On 23 February 2016 at 19:45, Peter Morris <[email protected]> wrote: > When I say 'breaks ducks' I mean it breaks the implicit interface contract. > > I expect it to quack when I expect, not bark. > > On 23 February 2016 at 15:49, Graham Ashton <[email protected]> wrote: > >> On Tue, 23 Feb 2016, at 03:31 PM, Peter Morris wrote: >> >> > but having #save raise an exception breaks ducks. save doesn't raise >> exceptions. >> >> If it would be an error to call `#save` on a missing basket, your code >> won’t do it, so there’s no problem. If you make a mistake and your code >> does do it, you want to know about it, so you really want it to raise. >> >> Can you elaborate on what “breaks ducks” means? I’m finding it hard to >> describe what I think you’re trying to say. As in, what’s the actual >> problem? >> >> Are you saying that any object that quacks like a Duck must have the same >> API as Duck, even if you never call some of those methods on the duck-like >> object? >> >> Here’s another way to think about it… >> >> If I wrote `Basket` and `MissingBasket` from scratch (without >> inheritance, or ActiveRecord), and needed to call `#save` on both of them, >> I’d implement it on both of them (reusing code as/if appropriate). >> >> If I only ever needed to call it on `Basket` I wouldn’t define it on >> `MissingBasket` as well, just because `Basket` needed a `#save` method. >> >> -- >> 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. >> > > -- > 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 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.
