“Clients may resort to guess-and-check programming to find all the methods that need to be invoked in order to make the object usable. The solution is to ask for fully-initialized dependencies in the constructor. For example, instead of connecting to a database in a constructor or an init method, add a constructor parameter for either an open Connection object or preferably for the actual queried data.”

In my particular case I am using JMS, here you have QueueConnections, QueueSessions, Queues, and QueueReceivers. I have a class that is responsible for receiving messages, so requires a QueueReceiver. Now, based on the above, this class should ask for a queueReceiver. However, a QueueReceiver is created from a QueueSession (session.createReceiver(…)) and a session is created from a QueueConnection (connection.createQueueSession(…)).

Now, depending on the way the session was created, messages received by the QueueReceiver need to be handled differently. In my particular case, I need the session created with the following parameters, createQueueSession(false, Session.AUTO_ACKNOWLEDGE), if different parameters are used, the application may not behave as expected. Where should this logic go, though, an inject method, a helper, a provider? and how does my class ensure it is passed a receiver created by the right kind of session?

Additionally, the connection that was used to create the session needs to have had its start() method called, or the receiver won’t receive anything. Again, what is responsible for calling this start method? How does my class ensure the connection was started?

I have a feeling that this is possibly the responsibility of providers, and I should have a StartedConnectionProvider and a NonTransactionalAutoAcknowledgeSessionProvider, and a NonTransactionalAutoAcknowledgeQueueReceiverProvider. The NonTransactionalAutoAcknowledgeSessionProvider would ask for a StartedConnectionProvider in its constructor, and the NonTransactionalAutoAcknowledgeQueueReceiverProvider would ask for a NonTransactionalAutoAcknowledgeSessionProvider in its constructor, and my class would ask for a NonTransactionalAutoAcknowledgeQueueReceiverProvider. Unit tests could then perhaps be written for the providers to ensure they return the correctly configured objects from their get() methods.

Is that the right kind of approach, or is there a better alternative? I guess one answer could also be that it should just be the responsibility of the injectors, and it is down to scenario tests to ensure the glue is sticking things together correctly.

We’ve found many articles on this site to be very helpful in educating us about our bad practices, and how we can improve matters.

I found this link to Chad’s approach for DI particularly enlightening, as it was the first to give me a better idea of how it scales past trivial examples, and how it could be applied to our own code.

However, one of my colleagues is strongly opposed to the use of statics anywhere in our code (they are, in a large part, what we are looking to remove, so why do so by adding new ones in?), and also isn’t a big fan of Chad’s injector pattern.

We’re hoping someone could offer some insight on the benefits/negatives of using the static injectors over using the factory pattern Misko shows in articles such as: http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/

Also, are the static methods in Chad’s version a temporary solution, to be refactored out later, or the final state?

I’m wondering why you used statics in your injector code. Why not create an instance of your injector and then use that?

I feel that this would be useful because others could extend your injector, overwriting perhaps just one method to wire together different service objects.

Many thanks for the DIY DI guide. It was a very enjoyable read.

One thing I’m currently puzzling over at the moment is how one would go about implementing configurable injectors. For example, if you were using DI injectors in an application that is capable of connecting to multiple database types. Is the correct way to do this to use providers?

In DIY-DI, exceptions will be propagated normally, regardless of which phase they are thrown from. So my opinion is that it’s not a problem. With Guice, some exceptions can get swallowed, so you should use ThrowingProviders liberally, and then it’s not a problem.

It’s important that your source code shows a clear separation between glue code and business logic, but less important that there is a strict boundary at runtime between the two.

Although I have a question about the article:
In step 7 you introduced SettlementCalculator to decouple two service objects so they collaborate through the value object – settlementAmount. But while you were doing that, you actually moved execution of your business logic from bookingService.buy() method to the phase of object graph creation. Isn’t it something we should avoid? What if statementCalculator.getSettlementAmount() throws an exception or reads from hard drive? I thought that first line in the main() method is just about object graph creation and ALL work should done after that, i.e. in bookingService.buy().