It’s good design if it’s elegant, and it’s elegant if it’s simple and clear. A call to Dir likely has some meaning within the context that it’s used, like your example of “CreateNewStagingArea” above. Adding meaning adds clarity, but adding another class abstraction isn’t a slam dunk, as you’ve also pointed out.

I’m using the definition of “elegance” that Edsger Djykstra was fond of, one that mathematicians use. This is a commentary of his about abstraction, “the purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.”

The point I was making earlier is that I’m not terribly worried about using calls to Dir where ever they’re necessary because they will likely be represented by a higher-level signature that is already there to add meaning.

Strictly from a testing perspective, if the conditions are right, and elegance is not lost in test design, I’d functionally test the “CreateNewStagingArea” method at least once, and not necessarily need coverage over it subsequently from other tests. I might replace the method if the mocking framework added to the clarity of what I was documenting with the test, or I might just let it go. I would only mock the call to Dir when directly testing the CreateNewStagingArea if it was valuable to do so, and I wouldn’t make that decision based on black and white orthodoxy until I had more of the rest of the factors in play in my possession.

Ad I would likely name the method “create_new_staging_area” as an exercise to understand Ruby’s native idioms in hope that I would assimilate more of them through practice, rather than reinforce my existing C# biases :)

Louis – The Dir class forces your code to rely on a concrete implementation, instead of an abstraction. That’s not good design. But, it may be /acceptable/ design. Sometimes the extra abstraction step isn’t worth it, especially if the calls are all centralized in an encapsulated module.

def CreateNewStagingArea(name)
//…
Dir.new(name)
end

Is that Good Design or Bad Design? The answer is all about context. But my general guidance to someone showing me that is, no, it’s not.

I was reading something Giles Bowkett (a Ruby guy for those who have no idea who he is) had written similar to what Scott is talking about (my apology, I can’t find the link).

It was more about how all the effort to add safety to static languages has just made developers worse as opposed to improving code. Not exactly the same discussion, but it touches on similar topics.

We need to think about this before making broad “Bad Design” declarations.

In our code base, at work, we use dependency injection everywhere. It’s great. I love it. But the reason I love it is because our container does all the work for us. In the year and a half I’ve been here, I have yet to swap a class with another. It has never happened! If it wasn’t for the container and the features it gives us that have nothing to do with DI, I’d seriously question its use. So far, the only advantage I see is that when changing the constructor on a class, I don’t have to go edit anything else, because we don’t new-up anything.

I do understand the flexibility that DI gives us. It’s great. But to say that DI should apply to everything might be short sighted in my humble opinion.

I haven’t worked with Grails for more than a year, but at the time it was based on Spring. If this hasn’t changed, then it remains a framework that doesn’t take advantage of language strengths inherent in Groovy, and maintains biases – whether recognized or not – toward tool-based Inversion of Control and dependency injection.

Ultimately, I found Grails to be just more Java and C# style ceremony in language that didn’t always necessitate it. It was like trying to make a leap to a new paradigm by leaving one foot firmly glued to the floor, and not really ending up in any particularly good place.

Grails to me is like a limbo – an intermediate place that is nether one thing nor the other. It’s often the kind of thing that happens when people aren’t sufficiently at-ease with the full extent of the necessity for the commitment of our attention when making a significant leap.

The leap from Spring MVC to Rails was too big of a gap for many Java developers to commit themselves to. Grails is the nether world where they are currently stewing in the fixative power of that karma.

The same could be said about .NET developers’ susceptibility to the fixative power of ASP .NET MVC, and friends.

These aren’t technologies driven by an indomitable personal drive for excellence, they’re technologies driven by only so much pursuit of excellence that doesn’t cause us to face the momentary discomfort of paradigm shift and the momentary loss of personal social status that we’ve built up in the culture surrounding the previous paradigm.

At some point, we’re called to go all-in or else we only end up re-learning and reinforcing things that we already know and are already comfortable with.

I don’t have a narrow view of what modern static typing can offer, and I’m aware of the continuing efforts toward fulfilling the dream of fully safe code. I also know that the pragmatism of self-modifying code is lost in this pursuit.

And that ultimately, this pursuit is a pursuit of an obsession with purity that mistakes wholly-optimized software development effort for locally-optimized programmer expediency. As such, it remains valueless but to those psychologies who fail to recognize having been shaped for years by geek idées fixes.

It’s not something I’m interested in because it delivers far less holistic productivity than it trades for localized expediency. If “correctness” were the only bottleneck, I would value it much more. And ultimately, it remains a non-actionable point while it remains largely hypothetical.

When this particular geek obsession delivers on all pillars of product development optimization both on the procedural and organizational fronts, I’ll value it. Until then, I’ve got larger fish to fry – fish that are even bigger than any sense of entitlement to premature, next-generation tools by any group of people who have become overly-specialized in their favorite work step.

I don’t have a narrow view of static typing, I’ve got a dim view of it. That view comes from having chosen to get immersive, in-depth experience with technologies that challenged my own unrecognized fixation with static typing. What I learned from spending a couple of years in this immersion is that I previously didn’t have an informed basis to evaluate one against the other. Now I understand why static typing fails to contribute as much to product development productivity – except in a few exceptional cases. I have a much better understanding of when to use either, and that understanding is fed by knowledge and concerns that go far beyond the realm of what programmers tend to become distracted by.

Passing in interfaces to constructors (ctor DI) and using IoC to handle object creation has been my MO for awhile now.

But again, I’ve only really done this within Grails, C#, Java

Shocking, this came from a MVP. Please, just don’t somehow bring CQRS into this discussion.