That really helped clarify a few things for me. Thanks again.

I will continue on with Rails first. At least that gives me some established structure to work with as I learn the ropes.

I wouldn’t start with trying to replace classes with callable objects like blocks, procs, or lambdas. There are classes in Ruby and OO is still a perfectly good way to represent abstractions. I don’t avoid using classes, in fact, I use them more often then other kinds of representations. But I also use modules, and there are a whole other set of ideas that go along with modeling compositions with modules, and with dealing with the particularities of modules.

The only way to practice not thinking in terms of interface types, or not thinking n terms of types at all, is to force yourself to not think in those terms. If you pick at it, it will just continue to itch. Just stop thinking that way until it becomes natural.

Everyone experiences the panic of not doing things with interfaces and abstract types. You just have to take the step knowing that there’s going to be ground under your feet and there’s no fall waiting for you.

The challenge with using ActiveRecord models, frankly, is often more cultural that technological. Moving away from the DDD patterns to ActiveRecord initially feels like taking a step backward in what “proper” design should be, but it’s that drive for “properness” or “purity” that drives a lot of people to get caught up in the DDD orthodoxy without understanding why.

It’s a bit cold, but there’s really only one thing you can do: get over it. It is, in fact, something to get over. If I were working in .NET, though, I’d still create modules for persistence that are separate from model logic. That’s because .NET dependencies are static dependencies and this constraint means pre-formulating strict separation before hand.

If you used the Active Record pattern in .NET, it would likely lead to less overall simplicity as a measure of simplicity for the whole effort and the whole system, while in Ruby, the absence of static dependencies allows systemic simplicity to be sustained.

Ultimately, it’s a cognitive pattern that has to be overcome; what I called “un-learning”. It’s much harder to un-learn than to learn. Adding new habits to a blank slate is more work that moving existing habits aside while also doing the work to form new habits.

Ultimately, if everything could be learned without the formation of attachments like habits, it would all be a lot easier. But in the face of habitual patterns, the only thing to do is recognize their presence, and move on despite all of their protests about how “unnatural” these new patterns are.

That’s why I think it’s so much easier to start at Rails. At least with Rails, you don’t have to start from scratch, and your code can largely be held in an outer structure that lets you start with the basics of plain old class-oriented development that you already know.

One more thing about Rails, though: there’s no need for those Domain Service patterns in Rails. All of that code belongs in the model objects. And that can be one hell of a hurdle for .NET developers with the DDD pattern language bug – maybe even harder to accept that ActiveRecord in some cases. Nonetheless, it’s an exercise you have to undertake to make the transition.

The one advantage you already have over many Rails developers is that Rails developers often believe that the only archetypes in a Rails app are models, views, and controllers. Many Rails devs suffer from their own orthodoxy that leads to the unquestioned belief that all classes with code are model objects.

You already know that there’s more to a MVC app than models, views, and controllers. What you might not already know is that there are far fewer of those other classes than you likely need. But working in Rails and in the Rails ecosystem will show you all these things, and you’ll have to temper what you hear with your own experience, and you’ll have to temper your own habits. It’s a fine balancing act, and you’ll inevitably fall back to C# habits. Just question them and become more aware of them. One day, you might even have legitimate questions about the Rails way, once you get a firm grip on on the subtleties.

That makes sense. During my initial explorations of Rails I instantly noticed how they stepped away from some of the DDD hallmarks in favor of a more simple approach. The models are aware of their persistence to an extent, which was hard for me to deal with at first. Regardless, in hindsight my repository example was stupid as it doesn’t really apply here

I guess what I am struggling with, is how can I train myself to stop thinking in terms of defining behavior in the form of an interface or abstract class construct that is essentially “fixed”, and instead do it the ruby way. More specifically, how do I replace the interface/ class dependency approach with a more dynamic approach using things like code blocks in Ruby? It still eludes me.

In Rails apps, for example, there’s no corollary to a repository class. It’s not really needed, and the Rails community never got involved in using Domain-Driven Design that way.

So, this kind of comparison, as I mentioned earlier, isn’t one that can be made point-for-point.

Nonetheless, let’s say that you’re using something like Sequel in Ruby rather than ActiveRecord, and if you’re doing class-oriented programming exclusively, then you might indeed have something like a repository.

So, if I had a controller class that made use of a repository class, the controller code would likely instantiate the repository by calling its contsructor, or would get an existing the repository instance from some kind of Singleton pattern implementation.

There’s not much to show here beyond SomeRepository.new – unless of course you’re writing a framework. But like I said, writing a framework at this stage of learning might be a very bad idea.

The comparisons break down because the design patterns can be quite different, and desing can be modularized quite differently to reflect the capabilities of the raw materials of the design. The primary raw material is the language you’re using.

Specifically to your question, yes, you “new them up in the ctor”. But be wary of what you presume about “default implementations”, because this is part of an unrecognized bias of working in a pre-compiled class-oriented language.

The only time you have a default implementation in Ruby is when you choose to.

With C#, what you see in the editor is what you get. It’s all default implementations – all the way down to the turtles.

Even an implementation of an interface type – even though you might not see it as a default implementation – is indeed a default implementation. It’s just a replaceable implementation – but only at a class level. The class itself always defaults to the one and only implementation that it has.

If you want a default implementation to be anything different in C#, you’ve gotta irradiate the turtles in an attempt to re-write their genetic code so that they’ll carry your default implementations differently.

Thank you for taking the time to respond. I am already on the path to learning Ruby and at the same time “unlearning” my C# habits at the same time.

Still, I would like to see a little bit of code. Not an enterprise app, but something very small. For example, some class that takes an IRepository or ISomeService to coordinate and do some work. In C# we may only have one implementation of these interfaces but use these abstractions to promote good design and testability. What does the Ruby version look like? Do we just new them up in the ctor with default implementations as you may be hinting at?

I want to reiterate, as I have for many years, that material serves one level of learning – the beginning, and that experience serves everything that comes after the beginning. Far from being armchair philosophy, it’s something that is observed by people who make transitions from the basics of practices, to intuitive mastery of practices.

Unless you’ve realized this for yourself, you will continue to have every confidence that what you know about learning is true of all of learning.

I’m not holding anything back. I spend one hell of a lot of time teaching face-to-face because I know that material learning just doesn’t cut it. In fact, all it can do is get you started.

I know that you want to see point for point comparisons of C# to Ruby. I know that point for point comparisons don’t do much more than reinforce the one-sided understandings that we already have.

I understand that this is a frustrating answer, but it’s the real answer, and it’s an answer that will be given to you by anyone who has experienced the breakthroughs, a-ha moments, and epiphanies of learning, and more difficultly, the realizations of un-learning.

As a more practical matter, I personally can’t afford to invest in building such materials, And because my experience in both learning and teaching has shown me that these things don’t really bridge the gap as we think they might from the outside, I’m reticent to invest in that kind of material. It’s not the kind of teaching I do, and I’ve never seen anyone do it effectively, and do it without creating yet more misunderstanding.

The learning return on that kind of teaching investment is too little for me to invest into it as a teacher – no matter how much you believe you’ll learn from it. I’m not saying this as an armchair philosopher, I’m saying it as an experienced philosopher – in a very literal sense of “philosophy”.

Here’s what you can do right now that will indeed clear up all of this lack of understanding: build an application on Rails. Or better yet, build a business on an application built on Rails. While you’re doing it, keep an eye out for difficulties that you feel would be solved with dependency injection. I think you’ll find vastly fewer of them than you might expect. In the mean time, you’ll have built an app and maybe even a business. And in the process, you’ll have undertaken experiences in learning, and more importantly, in un-learning; in recognizing unconscious biases that direct our ability to learn.

So, you could require me invest in creating a curriculum of material to demonstrate something that I’m very confident won’t have a profound effect, or you could make an investment in understanding on your own by installing Rails, watching some screen casts, reading a book (or three), and using practice and experience to shake loose the un-learning that does create realization.

If you believe that it’s my responsibility to spoon feed any petitioner to greater understanding, then I’ve failed to clarify my position on this kind of learning and teaching over the past five or six years.

Nonetheless, and with great sympathy for your predicament, I’ll offer this: I can’t show you a point-for-point comparison between C# using interfaces and dependency injection and Ruby. These are structural design issues, and they can be very different in either language. And where they’re similar, they’re only profanely similar; the powerful pervasive subtle differences aren’t revealed. They’re revealed through practice.

But a little bit of indulgence nonetheless…

At a very high level though, there are no interface types in Ruby, so there would be no interfaces types. And there’s very little need for an object container in Ruby, so there’d be no dependency injection framework as per what “dependency injection framework” means in C#.

That said, if you’re writing a framework, you’re going to come across dependency management issues. But if the first thing you do in Ruby is invest your C# biases in a new framework in a language that you don’t have fluency with yet, you’re probably letting yourself get ahead of yourself.

And if you’re writing application code within a framework context like Rails, you’re extremely unlikely to need a dependency injection framework and an object container.

What will you use other than static dependency injection? Non-static dependencies – because all dependencies in Ruby are non-static. What’s in the code is just a “hint”. You’ll use object constructors, and Singleton patterns. At a more advanced level, when creating plugins and frameworks, you might add lazy evaluation patterns and configuration patterns.

Specifically, take any C# code that isn’t framework code, remove the interfaces and remove the dependency injection. Replace the dependency injection with calls to constructors (also called “initializers” in Ruby) and Singleton patterns.

At that point, you’ll have the material in our hands that is a beginning to a comparison between C# and Ruby. Heck, you could do this in C# to see what the Ruby might look like, but it still won’t be too terribly representative, and that’s because you can’t represent Ruby thinking with C# thinking, no more than you can represent C# thinking with UML thinking.

To get Ruby, do Ruby. To overcome C# bias enough to get Ruby, do Rails. To get Rails, do something real with it. I’ll eat my hat, your hat, and the collective hats of the entire community if you don’t come back later and corroborate everything I’ve said here – even the stuff that you believe is armchair philosophy.

I’m not trying to be evasive here. I want you to know as much as you need to get an understanding. But I am saying that this kind of understanding is had through experience, and in this case, it’s not experience, that is difficult to get your hands on. It’s not esoteric, it’s just presently obscured.

I’d love to see a github repository of a Rails (or Sinatra app) that is coded the “Ruby Way” with complete tests, exception handling, etc. that I could use as a nice guide.

I think Roco hit the nail on the head there. I don’t even need the C# version for the code, although someone writing a blog post showing both would be fantastic.

I’m sold that Ruby is “better”, I’m sold that having a framework with testing/DI baked in is “better”, now I just need to see some good examples of it, and unfortunately, they’re not that easy to find.

How about something like, “Here is an example of a common task as it would be implemented in C# using interfaces, IoC container, i.e. standard C# practices, and now here it is in Ruby.”

It can be a trivial example, just something that highlights all of the topics that have been touched on at length in recent posts/comments.

As a Ruby newbie, I would really appreciate it.

What is it specifically that you want an example of?

I’m asking because some things can be exemplified in materials (code, etc) and some things can be exemplified in experiences (doing, practicing, learning, realizing).

If what you’re looking for can be exemplified in material, I’ll do my best to point you to it. But if it’s something that can be exemplified in experiences, I hope that you won’t be put off if I say that you can only see it through the lens of your own breakthroughs – just as Greg has with a growing awareness of intention-revealing interfaces.