> > 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. >
Sorry, should have said "frameworks" in there somewhere, > 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 see the logic, but still you hard-code a lookup-name in to the "resolver" for the dryrb factory, it's hard-coding access to a "bag of types". Sure it might have some up-sides, but I don't think passing in collaborators has any downsides. In fact, I'd argue that passing your collaborators around, rather then looking them up in some pseudo global scope makes reading the code simpler, as you can see roughly what your collaborators take and do vs having to contend with a lucky-bag of stuff you get from somewhere. > 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. > Jamis has some very relevant experience, some of the libraries he wrote are corner stones of the Ruby ecosystem, not to mention him having been a founding member of 37Signals, I wouldn't write off his credentials so easily :) That said, Net::SSH is a rats nest, but probably that's a problem of the space, before being a problem with the author. Remember too that Jamis hasn't *really written Ruby since about 2008 [sic, at least he's been out of the scene]*. 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. > I think your statement might be fair for someone who uses RSpec, but MiniTest encourages good modularization, isolated and scoped monkey patching for stubs and mocks and rewards a good design without inflicting TDDD (test driven design damage). An exchange of ideas is always contentious, we have our own camps :) I'm thankful for an eco system and environment in which everything can co-exist. Probably the root of most differences in perspective is personal bias born of past experience and the jobs we've most recently done. For me it's been almost all Angular, Go and Rust lately, and there "pass all the things around" is par for the course. -- 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.
