Oct 30
Maybe hiding initialize in your abstract parent class is too much abstraction?
Or the wrong one. It just seems like over-inheriting is definitely one of the bigger maintainability nightmares I have had; and pulling the constructor entirely into the parent.... Well it better be exactly the parent, and cleanly done.
It's like those overly abstracted resource_controllers. They seem like a great idea, but once you start deviating at all, you spend more code and more time thinking about how to write that code to get out of the straight-jacket over over-inheritance than you would have had in the first place.
I'm starting to feel that while abstract constructors *can* be done right they are often are a smell. Compare these three approaches and let me know what you think:
A child in an inheritance chain should be interchangeable with the parent - meaning I should be able to use GoofyScraper wherever I could use any AbstractScraper. Since GS is initialized differently than AS, that rule's being broken.
ActiveRecord gives us an #initialize method, and it works just fine by me. If I find myself having to override it, then I'd tend to think that I was doing something, well, goofy.
It's just that when I have a folder full of children, that vary slightly enough to not yet be worth a whole 'nother branch of inheritance, hiding init makes it confusing.
Yeah, I almost never overload init in AR. Maybe that is part of the difference between the need to cleanly abstract a library all the way out, versus client code interacting with itself.
That's a totally valid position... just wanting to clarify.
Foo away, OTOH, do it wisely and consider composing into modules instead, even then.
Contrived examples are problematic. I am still not sure I like not being able to see init in the leaf class, unless it is inheriting from a very well known library, with a decent API, like ActiveRecord