[...] friend of mine has put together a set of documents which talk about do-it-yourself dependency-inject. Being that I am a fan of DI and how it helps with testability I wanted to share it with you. It is [...]

Page numbers would have been nice on the pdf, in case I drop them and they’re not stapled and get out of order.

Sorry; before I criticized I should have thanked you for such a nice write up!

Thanks again; this is very helpful.

Thanks Rusty. I’ve added page numbers.

Yes, this is put together nicely, thank you.

Great write up and good examples! Thanks!

Hi!

I have a question about the article. In step 5 you removed the parameters from BookingService’s buy method, and added to the constructor. This modification introduced an – in my opinion – unnecessary state to BookingService. From this point, if i want to use this service, i always have to create a new instance (cannot share the instance across multiple invocation), and i always have to deal with the constructor’s parameters. Wouldn’t it be easier to use the BookingService’s earlier form (from step 4)?

ps: Sorry for my english, it’s not my native language.

Péter, the intention in step 5 was to make it easier to acquire a BookingService. I know that’s counter-intuitive, because of the reason you describe. The BookingService dependencies are not easy to construct. So callers would be over-burdened if they always had to say:
BookingService.buy(Account.getCustomerAccount(accountKey), new Trade(symbol, quantity), commission);
Most would prefer:
booking.buy();
Plus, those callers would prefer the looser coupling with accounts, account keys, trades, symbols, quantities and commissions.

Fortunately, in a DI-infected application, that extra BookingService state does not tend to create a problem. Anyone that needs a BookingService simply asks the injection framework for one, and a fresh instance is provided. If multiple instances were undesirable, then the BookingService could be left like in Step 4, and the request-specific state could be moved to a BookingClient class instead. Then BookingClient would have constructor parameters for accounts, trades, commissions and the BookingService instance.

I love this silde. I was finding for example like this a half year. DIY-DI, refactoring approach to make code testable and combing some OO principles. Better than many selling books. Thanks.

Hi,

Great ideas and very clearly expressed! I have a couple of questions, though:
- In your Injector examples, you always create new instances of the things that you inject. For a lot of object graphs you’ll probably want to reuse the same instance of some objects and inject that into multiple other objects. In such a case, would you typically cache that instance in the scope (making it mutable) or in the injector class or is that some third thing?
- I’m not quite with you on the “don’t use mock objects” issue. Could you elaborate on that? It feels like it is quite common that one object wants to trigger something to happen in a collaborator. Of course, the data exchanged between the objects can be represented as primitives/value objects, but the actual event of triggering something cannot as far as I can figure. I guess that could be made a part of the wiring up, but that seems like it would hide important and testable business logic. Using mock objects feels like the best way to check that sort of thing.

Cheers,
Petter

[...] This post was mentioned on Twitter by skim, Jilles van Gurp. Jilles van Gurp said: Currently Browsing: ^[7] great article on do it yourself dependency injection and design considerations [...]

Petter, my thoughts on caching mirrored yours. I didn’t get into it on the slides, but you can see the description of a clean technique in the DIY-DI.pdf. Look for the section titled “Caching” near the bottom of page 11.

Mocking is still necessary in some cases, like where the production objects need to perform operations in a certain order. So maybe the best advice is, “Think twice when you find yourself using mock objects.” I find that the more DI code I write, the more I use functional programming idioms. Pure functional programs still have complex interactions but they typically do it in a way that could be tested without mocks. For example, suppose you write a class that configures a static logger. You could have that class produce a token, as a proof that configuration was performed. Then any classes that need the log configured can ask for that token as a dependency, rather than calling the log configurator directly.

Very nice written and explained!

Do you happen to have any thoughts about using this with OSGi (or more precise with Eclipse plugins)? My first impulse is to use plugin scopes, but there is also the Eclipse platform with its tens of singletons and static stuff…

Vlad, the concept of Eclipse plugin scopes probably doesn’t overlap with the concept of DI scopes. I think that’s just an example of how the term has been overused. The plugin scopes contain static state, so hardcoded references to them would make testing difficult. You could use DI for developing a plugin though. Write your own scope and injector classes like in the DIY-DI manual. Then you can also write helper methods in the injector class to provide each of the static resources in the Eclipse plugin environment.

Thanks for the suggestions. An Eclipse application usually involves several plugins and this is where it feels tricky. I think that what I meant with ‘plugin scope’ is what you mean by “your own scope”. The conclusion, I suppose, is that it’s not trivial.

In your PDF manual you say to make trivial doGet and doPost methods for a servlet implementation. I can see how those methods would construct a RequestScope object using the passed in HttpServletRequest and HttpServletResponse objects. I can see how to get a SessionScope from HttpServletRequest.getSession but how do I get my ApplicationScope object?