Comments on: Dependency Injection Myth: Reference Passing

By: Test Driven Development

Test Driven Development — Tue, 17 Nov 2009 16:34:09 +0000

[...] way I approach programming. When to use Dependency Injection, Guide to Writing Testable Code and Dependency Injection Myth: Reference Passing are some of the blog posts that I would definitely recommend [...]

By: misko

misko — Fri, 14 Aug 2009 17:24:37 +0000

@Dave,

Logging is a weird case, because the information flows only one way, from your application to the logger. More importantly your application does not (should not behave any differently) if the logging is enabled or disabled. For this reason even thought logging is global state it will not hurt you, so I say just do Logger.getLog(…) right where you need it. However, if in your test you need to assert that a particular message did get written to a log, than you have no choice but to inject the logger through the constructor. GUICE will do this for you automatically.

By: dave

dave — Thu, 13 Aug 2009 21:40:55 +0000

Misko, I agree best to request dependencies in the constructor for most case but how do you suggest DI for something as ubiquitous as a logging object? Since I think you advise against factories and I don’t want to cascade the logging interface request into every constructor that might log, I’m at a loss on how to do this efficiently and cleanly. I’m thinking about using a proxy factory that a delegate must be set into by the production or the testing application. If you recommend using a container, how is that different from a factory and how do you normally access that container from objects which may have been instantiated by a production vs. a testing container? Again the only way I can think of is to have a container proxy which has a delegate set into it by the actual container. Maybe container and factory are really the same thing? Thanks, Dave

By: Giorgio Sironi

Giorgio Sironi — Wed, 27 May 2009 20:53:45 +0000

@Misko:I found your article Where have all the singletons gone?… Translating in that example, I was worried that RequestFactory has to know about everything the objects it creates need. After coding I think it makes sense, even if RequestFactory creates third-level factories to pass in the constructor of objects that absolutely need to create their dependency dinamically. My coding was on a Mapper for database tables that needs to create a table Introspector for each record and subrecord it has to save. I resolved with a IntrospectorFactory.

By: misko

misko — Wed, 27 May 2009 19:15:00 +0000

@ Ryan,

why do you need a God class? Everyone just knows what they need to know. Factory knows about everything which it is responsible for instantiating. Where does God class come in?

By: Ryan

Ryan — Wed, 27 May 2009 17:27:43 +0000

It looks clean, but isn’t this requiring a god class that needs to create everything? If you want to create a LoginPage, you have to create a UserRepository and a Database. This becomes a pain when you move outside an example to deeper and wider dependencies.

By: misko

misko — Mon, 25 May 2009 00:12:16 +0000

@Giorgio,

I am having a hard time follewing your example without an example code, but I think you are on the right track and what you are saying is correct.

By: Giorgio Sironi

Giorgio Sironi — Sun, 24 May 2009 16:15:42 +0000

So it is now obvious that the application factory (or the container) holds the small-s-singleton: an instance of the Database object. What about construction of objects that have a small lifetime? For instance, a ArticleRepository could create Tag objects to send when a Article is modified; my approach is to make ArticleRepository to ask for a TagFactory in the constructor. This is an example of creation of non-newables (Song example) in the application logic, that is simply delegation to the TagFactory. It could be the same with any other object that is not created for the global application lifetime but only for a small one, and that has in the constructor some dependency to a general singleton like Database.So the TagFactory needs to hold a reference to pass to the Tag, right?

By: misko

misko — Tue, 07 Apr 2009 10:10:55 +0000

@Darren,

You have shifted the problem to the factory. Bu that is a good thing for many reasons. (1) Separation of concerns. (2) Separating of the initialization logic from the business logic and (3) guaranteed order of initialization.

By: Darren

Darren — Tue, 07 Apr 2009 02:32:46 +0000

While I agree with the sentiment here, I think there’s a bit of sleight-of-hand going on with these examples. With the Singleton example, it’s obvious how the UserRepository gets its db connection – it “fetches” it using a call to the Singleton, which probably makes a connection to the db if it doesn’t already exist. In the DI example, it’s not clear how the UserRepository gets a working db connection – basically it is just saying, “I’m not doing anything until you give me a db connection”. I suppose the assumption here is that there is some sort of DI framework or other implementation that actually injects an existing db connection. That may be, but it’s misleading to say, “Look how much cleaner the second example is” because you have stripped out the part of the logic that actually creates and injects a db connection into the object. How do we know that you haven’t just shifted the problem to some other layer of your application, eg. the DI framework?