yes, that is right on.

An injectable can ask for a newable (or a primitive type) in its constructor when the newable is used for configuration of the injectable and when the injectable treats the newable as a constant. So injecting, for example, an URL or a timeout value in an injectable might be an acceptable use when these are used by the injectable as constants for its configuration.

Is that understanding correct or did I mangle the message? Thanks!

very good observation! The issue with newables and injecting them in, is that the injector does not know how to make a String. Not any string will do, only a specific one in this case. So the rule holds, but in this case the String acts as a configurable constant. You would not instantiate the constant in your code, like you may instantiate an array or a hash, instead you expect someone to give you the configuration constant. Hence it should be injected.

I’m confused by this example and how to reconcile this with previous advice you’ve given about newables and injectables.

Is the Java Greeter class intended as an injectable or newable? It seems intended as an injectable since the article revolves around the ‘greet’ verb. But you’ve said previously (http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/) that “Injectable can never ask for a non-Injectable (Newable) in its constructor”. Clearly though here ‘greeting’ is a newable since it is a String.

But if Java Greeter is not intended as an injectable and is instead intended as a newable, then the whole example kind of falls apart since the example is about injectables but newables can’t be injected into injectables, so I assume that Greeter is probably not intended as a newable.

In any case, I’m been trying to resolve this in my head unsuccessfully. Have you changed your mind about injecting newables into injectables or (more likely) am I misunderstanding something?

Nouns and verbs need to be in balance. So perhaps a class (noun) is needed in your case to join the two.

I think I got caught red handed. You bring up a good point which I did not think about. You are correct that in this example the factory is a single method without a class which is a static method. But closures kind of undo the staticness of it. In java a static method is static and it has all of the issues I mentioned before, but in JavaScript the method has closure (variables declared outside of the method). This makes the method act as a class to which you pass the dependencies through the constructor (closure) and the class has single method which performs the action (equivalent to just calling the method).

So in JavaScript a method without a class has injection (closure) but it also has polymorphism, since the method is passed into the consumer, and you can always inject a different method for testing. So closure and methods as first class citizens undo the static method problem of Java.

Otherwise I’m a bit puzzled. You said before that the important part is that your tests must be able to prevent the execution of normal code path (or else you would end up with scenario tests instead of unit tests).