I understand that you could do a binding like “bind(int.class).annotatedWith(name(”httpPort”).to(8080);
and with manual DI you could simply hard-code the port number. But the question that remains is:

When you have a configuration file for specifying the port – where in
your application do you read the configuration file (needs to be done
before binding).

Could you please clarify this. Thank you!!!

You are very quick! You are right

WebServer (Configuration config) {
this.port = config.getPort();
}

This breaks the law of demeter and I would never do this. However this works just fine.

WebServer (int Port) {
this.port = port;
}

But as you correctly pointed out now we are mixing service and value objects. The reason this is a problem is that DI frameworks will not know how to inject ‘int’ as there are a lot of ints to choose from. But if you are doing manual DI this is not a problem. So to make DI frameworks happy we need one more step.

WebServer (@named(”httpPort”) int Port) {
this.port = port;
}

By adding the annotation to the parameter you can now write this in your GUICE module

bind(int.class).annatatedWith(name(”httpPort”).to(8080);

and everyone is happy.

to contrast this with something like CreditCard. That is not really injectable since in a system you can have a lot of credit cards and the number of them is dynamic at run-time.

– Misko

I have read the post you recommended and it says:

“However, Injectable can never ask for a non-Injectable (Newable) in its constructor.”

As far as I understand, the port is NOT an injectable, but the WebServer is. The problem I have is exactly the problem you mention here: “when you ask for things which Dependency Injection Frameworks can not provide”. What do I do then?

thanx, Artem.

Excellent question. Have a look at: http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/ The key question is can a Dependency Injection Framework such as GUICE know what do you mean when you ask for @Port int portNumber. And the answer is yes, there is not ambiguity. (You need the annotation since there are lot of ints but only one @Port int)

So the prfered way is to ask for the port number in the constructor. If you think about it it makes perfect sense. In order to instantiate a WebServer you need to know the port number. So ask for it in constructor.

I think the trouble you can ge into is when you ask for things which Dependency Injection Frameworks can not provide. Such as a Song. Well there are houndreds of Songs in the system, which one do you want? And annotation does not help since the Song list is dynamic.

– Misko

Assume that you have a WebServer class that controls a web server instance. It has a constructer like

WebServer (Configuration config) {
this.port = config.getPort();
}

This breaks the law of Demeter and I want to refator it. But hey, I can’t move the port to the constructor. This way I will be mixing the service-objects with value objects. And my application factory will have to know how to get the port configuration out of a config file which means doing work in the factory.

Another way to refactor it is to move the configuration options to the start() method like this.

// This is a test code, not a production code
WebServer server = new WebServer();
server.start(8080);

But this obligates the callers to know what port they need to start the server on, which again breaks the law of Demeter, because they shouldn’t need any configuration options they do not directly use.

Please, advice me on a way to refactor the code with Dependency Injection and the Law of Demeter in mind.