we’ve also had some serious monkey wrenches thrown our way since i wrote this, and it looks like this code will have to sit for a while. this is probably a good thing, though. when we do come back to it, i’ll have a better idea of how painful and/or poor the structure is – i’ll have forgotten what i was thinking by then, and having to relearn it will expose a lot of problems i’m sure. i just hope i can find good solutions when i finally do see the problems.

scott – that’s a lot for me to consider, and exactly the kind of insight i was looking for. looking back at the original decision on this inheritance chain, it’s rather obvious that we chose it because we didn’t know what else to do. it was easy to fall back into this because we had both done it in C# for many years. the dynamic nature of ruby combined with mongoid made it even easier, too.

i’m seeing a lot of concerns bleeding out in very strange places in my code right now. i’m not sure if the inheritance is a cause or a symptom, or both at this point. i need to re-evaluate a lot of this code and throw together a few prototypes to see what it will take to move away from inheritance.

more importantly, i think, i need to re-evaluate some of my abstractions and find out why so many of the concerns that my classes have feel like they’re being tossed in as after-thoughts instead of modeled as real parts of the system. perhaps the inheritance is making it easy for me to make bad decisions on this front. it certain feels that way.

The ultimate issue is that it’s inheritance for the purpose of reuse rather than for hi-fidelity modeling of real world things.

Inheritance is the strongest kind of coupling.

There’s a Single Responsibility Principle concern in all coupling. When a class has another class coupled to it, it serves that class as its master. When a class has two classes coupled to it, and if those classes are concerned with dissimilar things, the coupled class serves two masters. Now it has two reasons to change. Now rest squarely in the sights of SRP problems. Those problems may never arise, but potential is now locked and loaded.

DHH wrote an essay a few years ago about using modules rather than base classes in Rails if he could do it all over again, so we can’t look at ActiveRecord as a justification. That “justification” has already been debunked. In the end, factoring ActiveRecord::Base into modules didn’t happen in Rails3 because even though the problem potential was “locked and loaded” it wasn’t really causing the kind of harm that justified the level of work needed for that change. Sometimes, coloring outside of the lines is a choice we make. Making the choice unconsciously is the ultimate problem.

You could have implemented the reuse in your model with modules, and in the end, it would have been a “truer” implementation, since the purpose of modules is more closely aligned with reusing something rather than extending identity to something. You might have chosen inheritance (sub classes) rather than composition (modules) because of class-oriented programming bias, who knows.

Regardless of what answer you find, it’s the right question to ask of this design, and finding previously-unknown biases is like being released from shackles that you might not have known you were in. You can still choose to wear the shackles if you like the aesthetic, but you risk being tossed in jail by a cop who mistakes you for an escaped convict. Unforeseen design changes happen. Clean and proper use of patterns can help keep us free of unforeseen cost of change regardless of our aesthetic preferences.

Here are two posts that I found useful:

http://www.thedotnetfrog.com/2008/05/30/choosing-composition-over-inheritance-yet-another-example/

http://www.ronaldwidha.net/2009/03/22/a-good-example-of-favouring-composition-over-inheritance/

Seems to me that the usefulness of C/I has more to do with behaviors than data. For instance, with your “question” scenario, if you have to implement different validation techniques for different classes – and especially if some classes share one implementation while others use another, then it’ll be easier in the long run to implement the validation logic outside of the classes and have them injected where needed (or for that matter to use a visitor pattern – which seems to be pretty damn’d similar to the idea of composition).

As far as just specifying what fields are in various classes, I don’t see how you can make it any more straight forward than to use inheritance.

I agree with Bob, Travis & David. If you can get around town on a moped, there’s no point in driving an SUV. Use the techniques that make the most sense, and ignore the code-guru dogma. If the reason for using a particular technique isn’t self-evident, then it’s probably not the right technique.