What amazes me is how many people have never heard of OCP, SRP, LSP, etc. When I first read about OCP I want to say my skills as a programmer went up a couple of notches right then and there. This stuff taught me how to think in an object-oriented way. It’s immediately useful, which just fascinated me to no end when I first discovered it.

The company I work for in Houston runs an internal bootcamp for new hires right out of college. Guess what I am going to teach? Maybe, following your call, I’ll post it all on my lame blog.

I guess it depends on whether you’re building a system which happens to have a web interface, or a web application based on RoR.

If you’re all in to RoR then AR makes perfect sense because you’re not going to use it for anything else.

But what about when you’re not making web applications, or rather, what about when you’re making your own framework that provides business logic that can be used by a web application, a backend service (web service), or maybe even out in the field disconnected on a field engineer’s laptop?

I need to build my model to serve the business need. Not serve the database, or a web framework, or any other framework/context in which my model may run.

My model and associated business logic has no inherent need to be tied to a database, IoC container, or anything else so why should I go about tying myself totally to one of those things?

To your Ruby example, I have alot more flexibility in Ruby because isn’t using static type-checking at compile-time. If I wanted to swap out my ActiveRecord model for a DataMapper model, I just have to retain the behavior. My DM model simply has to quack like my AR model. Because my business logic isn’t dependent on implementation details such as the parent class of the model, I am free to make changes as long as I don’t change the behavior my application uses. I can’t do that in C# because the static type-checking won’t allow me to swap out models without recompiling my application. This is the crucial difference between polymorphism through composition vs. inheritance, and the late-bound nature of dynamic dispatch vs. the early compile-time type-checking of static languages.

While you make a great point about ActiveRecord models requiring a database to work, I don’t think this is as much of a real world hurdle as you might make it out to be. In the case of AR, the dependence of the database is serving a very specific purpose. If you want to use a model in a different way or for a different purpose, you should use either a different library (like DataMapper) or a completely different approach (like RESTful web services, or a document based database, or memcached, or whatever). Every abstraction leaks, and there is no silver bullet. So rather than depending on a framework to offer infinite flexibility and do all the heavy lifting, we are free to choose the implementation that makes the most sense for our needs. In short, you approach the problem differently.

I chose Ignorance over Agnostic on purpose because you don’t want your code to be totally dependent (i.e. compiled/interpreted-against) a specific framework.

(loading standard anti-ActiveRecord argument in 3… 2… 1…)

I have a domain model. It gets persisted somehow, I don’t care. In a separate assembly/dll, I have all the stuff that cares about how the model gets persisted. I could chose to switch off NHibernate and go with something else in the future, or maybe I want to use the domain model in-memory with persisting anything. Having my classes attributed heavily or having to derive from interfaces or base classes violates this. now, whenever I want to do anything with my model (even if I don’t need to persist or retrieve anything from a database, I now have to lug along NHibernate or Castle ActiveRecord (and probably have to have a bunch of junk in my config file) just to make those two happy when I don’t even care about it.

Likewise, in your Ruby AR example, you are completely tied to AR. Hopefully you won’t have to ever use your model for anything other than RoR work because you’ll be SOL for the most part.

Sure, you could code around it, or find a way to host it without a database or something, but now you’re having to worry about it.

Instead of the persistence mechanism serving (transparently) your model, your model is serving the persistence mechanism.

At first I was fearful that the second half of this post was going to rail on me for not knowing every little detail of every framework out there. I thought you were going to say that being ignorant of said frameworks is an anti-pattern and that I should repent. I’m glad you haven’t forced me to face my sins.

Actually, I think the principle is misnamed. I think it should really be named something like the Framework Agnostic Principle. The more I think of it, “agnostic” might not be the right term, but I don’t know a better one. I want it to mean religious, but not a believer in any particular church or sect. Perhaps anti-disestablishment non-sectarianism is a better term? I dunno. Basically, you don’t need to be ignorant of the framework, just don’t give yourself fully to it.

That said, and at the risk of repeating myself, I tend to think that the existence of so many “frameworks” is a sign of trouble. In Ruby, we don’t consider ActiveRecord or Sequel or DataMapperto be frameworks; they are simply libraries. The fact that we need, or think we need, a framework to solve our problems gives me pause.