> 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.
The idea is that you register with keys generic enough that you can swap out the implementation and change dependencies using the same keys, a lot of people have a similar reaction to the thought of IoC but I find it useful, each to their own I guess. > 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]. I don't doubt that he knows his stuff, I just like to try things out for myself and build my own experiences, perhaps standing on the shoulders of giants is the intelligent decision though. > 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). I haven't used MiniTest myself, so yeah only talking from my experience with RSpec. > 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. Definitely. Sorry if I came across as confrontational, that wasn't my intent, always hard to convey your intended tone in text-based conversation. Nice, been meaning to look into Rust for a while. -- 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.
