On Tue, 23 Feb 2016, at 02:51 PM, Peter Morris wrote: > > I see what you mean with ducks, and I know I shouldn't care, but I find I > still do.
Please don’t take this the wrong way, but perhaps it’s worth getting used to not caring? My code got simpler once I embraced duck typing wholeheartedly. > Maybe overriding save in MissingBasket to just return nil or false. When I said I wouldn’t want somebody thinking they could call `#save` on `MissingBasket` I didn’t mean I was worrying about what would happen if somebody did call it, just that people would think `MissingBasket` was persistable. We’d have confused them by setting up the parent/child relationship. And if you think about it, `MissingBasket#save` makes no sense in the domain (i.e. as a concept in the world we're modelling). So it seems reasonable to me that calling `#save` on MissingBasket should raise an exception, and `NoMethodError` feels like a good one to use. The same applies to the majority of the other methods on `Basket` that we’d inherit if we subclassed it. But nevermind all that, I still think it’s well worth avoiding writing this at all costs… class MissingBasket < Basket To experienced Rails developers joining the project that would indicate we were using STI, and that would break a lot of their expectations (e.g. there’d be no type column in `baskets`, etc etc). Substituting a simple object that behaves like a basket is the only clear self documenting approach I can see here really. Maybe there are more, but I can’t see ‘em. -- 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.
