The Clean Code Talks - Don't Look For Things!
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions about dependency injection, service locators, constructor logic and the Law of Demeter, as a clear explanation of why classes should be handed their dependencies.
Recommended by 45 people across 53 different months, 2009 to 2021.
Why Code Review Stack Exchange recommends it
Code Review Stack Exchange answerers point people to it when reviewing code with constructor logic, service locators, or scattered new operators, to explain dependency injection and honest dependencies.
Recommended by 2 people across 2 different months, 2013 to 2014.
Why Software Engineering Stack Exchange recommends it
Software Engineering Stack Exchange answerers link it when explaining dependency injection, service locator problems, Law of Demeter style design and why scattered null checks hurt testing.
Recommended by 2 people across 2 different months, 2013 to 2016.
What it is
A 2008 Google Tech Talk by Misko Hevery in the Clean Code Talks series. He argues that objects should ask for their direct collaborators in the constructor instead of looking them up via service locators, singletons or deep object graphs, and shows how this makes code testable and respects the Law of Demeter.
What people said
Strong rec cg. · 2009-02 · Stack Overflow · on “What things are best not done in a constructor?”
To improve the testability of a class it is generally a good thing to keep it's constructor as simple as possible and to have it ask only for things it absolutely needs. There's an excellent presentation [this video] available on YouTube as part of Google's "Clean Code Talks" series explaining this in detail.
Strong rec Jean-François Corbett · 2012-02 · Stack Overflow · on “Is it acceptable to use exceptions instead of verbose null-checks?”
I highly recommend watching this video: The Clean Code Talks - Don't look for things! [this video] . Afterwards you will realize that the null checking and the exception tactic are really just two alternative band-aid solutions to a more fundamental problem. The real answer is: refactor. (If you have access to the code, of course.)
Strong rec bikeshedder · 2013-01 · Stack Overflow · on “Alternative to passing IOC container around”
I added a small example which illustrates what I mean. I highly recommend watching The Clean Code Talks - Don't Look For Things! [this video] which explains this concept very well.
Strong rec qrazi · 2013-06 · Stack Overflow · on “How mock new object in method - phpunit”
I am no expert myself. I do think that writing tests also makes the code itself cleaner, because you think better about its structure. [this video] and [LINK] are good general talks, and [LINK] for a depency injection argument from the creator of Pimple and other great projects...
Strong rec Wrikken · 2014-02 · Stack Overflow · on “Should a model object instantiate inside a controller class?”
`new` is for factories, and in a very limited amount of code. You want to avoid calling `new` in business logic. this talk takes +/- 40 minutes, but is well worth your time [this video] .
Strong rec anon · 2014-06 · Code Review Stack Exchange · on “Do the objects in this code follow OO standards?”
I think by far the most important advice I could give you is not to do any work in your constructors. Look up dependency injection [LINK] . It basically states that you should ask for the objects that you need directly, instead of asking for building blocks and using those to construct your dependencies yourself. So a simplified example: //The wrong way, doesn't ask for what it needs, lies about its dependencies. public Foo(Bar bar) { this.fooBar = bar.getFooBar(); } //The right way, asks only for what it needs. public Foo(FooBar fooBar) { this.fooBar = fooBar; } I recommend you watch this lecture [this video] by Misko Hevery, who explains this very well. On an unrelated note: even if your constr
Strong rec Adi Levin · 2016-02 · Stack Overflow · on “Test Class which uses object Geocoder Internaly”
Yes. Pass the geocoder in the constructor or in a setter method. This is the way to achieve testability. This is a great talk that explains why you should do this always: [this video]
Strong rec Barry · 2016-05 · Stack Overflow · on “Logic inside constructor”
No it isn't a good idea for automated testing. When testing you want to be able to "mock" objects that allow you to control the logic especially in terms of interfaces. So if you place logic in the constructor then it is very hard to test as you must use the real object. here is a fantastic talk with much more detail on why not to put logic in constructor (google tech talk by Misko Hevery) [this video]
Strong rec David Medenjak · 2017-06 · Stack Overflow · on “Dagger injected objects that create other dagger injected objects n levels deep and wide”
@DavidLiu the idea is that if every dependency is there, you do not have to pass the "injector" around, which is an anti pattern by itself. I always like linking to Google Clean Code talks [this video] which does a fantastic job on explaining the concept. You can just request dep1 and dep2, if they themselves can be constructor injected.
Recommends Esko Luontola · 2009-05 · Stack Overflow · on “Dependency Injection resolve and unit testing”
Is that a bad practice, to call resolve on the container? I could create the ServiceValidator instance in Main() and pass the object around, but that seems stupid as it would cause lots of parameters for the objects that are just passed around to the next method. When you use dependency injection all the way, then you won't need to pass lots of parameters to objects. The constructor of each object should have as parameters only those dependencies which it itself uses directly - it won't know about the transitive dependencies of its direct dependencies. So if you have a class X which requires a ServiceValidator, then class X will have a constructor parameter of type ServiceValidator. Then if