Hi Lee, I guess when you say "I've never felt the need for DI in Ruby" you're referring to dependency inversion? As you already posted indicating you advocate dependency injection in Ruby previously.
The difference here is that dry-container also works as a kind of factory in that it knows how to construct your objects, hard-coding the constant name (as a default argument or otherwise) means that the class using it as a collaborator needs to know how to construct it, change a class constructor and you have to update any references to that in classes that use it as a collaborator, thus breaking the open-closed principle. I had a quick skim of the linked article by Jamis Buck (as I've already read it a long time ago) and I don't think that using core-library features to prove or disprove the validity of design patterns particularly compelling, although he does a good job of making it seem so without going into too much detail. I do think there were a lot of valid points in there though, IMO using a DI framework does encourage you to think about interfaces, single responsibility, open-closed principle etc. The problem in Ruby is that we have test frameworks that have nice DSLs to dynamically monkey-patch for us, this means we don't "have" to think about boundaries and coupling as much because we can test our objects in isolation anyway - I'm not an advocate of changing code for the sake of testing, but when it makes your code more flexible it can only be a good thing. -- You received this message because you are subscribed to the Google Groups "North West Ruby User Group (NWRUG)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at https://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/d/optout.
