By the way, I can see one class with 40 or more dependencies. This is what we call a Façade.

Best regards,
George.

bean class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"
p:requiredAnnotationType="Mandatory"

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Mandatory {
}

Register this annotation with the RequiredAnnotationBeanPostProcessor

You can now use @Mandatory on the setter methods.

public class Foo{
private final Service service;
private final SomethingElse somethingElse;

public Foo(FooOptions opts){
assert( null != opts );

service = opts.service;
somethingElse = opts.somethingElse;
//don't perform checks on opts, instead on local vars, as callers may have changed opts in the meantime
assert( null != service );
assert( null != somethingElse );
}
}

public class FooOptions{
public Service service;
public SomethingElse somethingElse;
get/set….
}

You could also use the getters/setters in the options bean.

IMHO the advantage of this approach is that if subclasses need further args, just subclass the options bean, and no further changes to your classes are required.

It would be nice if Java supported automatic generation of constructor options beans (ie like named arguments I guess), or allowed inner classes without the need for an instance of the outer class so that these options can be kept in the same file.

Another approach is using an interface:

public class Foo {
public Foo(FooOpts opts) {
//..assert(…)
service = opts.getService();
somethingElse = opts.getSomethingElse();
//..assert(…)
}

public interface FooOpts {
public SomethingElse getSomethingeElse();
public Service getService();
}
}

and an example usage might be:

Foo foo = new Foo(new Foo.FooOpts(){
public Service getService() {
return "My Service";
}
public SomethingElse getSomethingElse() {
return "SomethingElse";
}
});

My personal take on setters vs constructors, is that the setters clutter up the API you are trying to expose, and you also end up with a lot of boring boilerplate get/set. IMHO objects should expose business logic, and not all the other junk for settings the object up. In the case of an options object, it doesn't contain any business logic, its just a transfer object, in which case get/set is fine and doesn't add to the confusion

Does anyone know how to configure Spring to use the Common Annotations 1.0 which come with Java 6. e.g. @PostConstruct, @PreDestroy, @Resource and @ConstructorProperties ?

thanks for your comments. I'll try to update the blog post when I have time, because mentioning the possibility to mix constructor injection and setter injection is definitely something that should have been done from the start.

<bean id="blogCommenter" class="org.example.BlogCommenter">
<constructor-arg value="Chris"/> <!– first name, required –>
<constructor-arg value="Beams"/> <!– last name, required –>
<property value="S"/> <!– middle initial, optional –>
</bean>

Thanks for the thoughtful treatment of these two alternatives. Constructor vs. setter injection is something that often becomes a matter of religion. It's not nearly so black-and-white, and I think that (amongst your other points) drawing a distinction between the needs of application code vs. framework code is spot on. While I strongly prefer constructor injection whenever appropriate, there are certainly contexts where setter injection is preferable (optional parameters are the obvious case here). It's worth pointing out that these two approaches are not mutually exclusive either. I often mix and match constructor and setter injection, e.g.:

This is an overly simple example (one would likely never declare such a bean), but it expresses the idea.

As you mention, it translates to Java code that properly leverages constructors to ensure an object is always in a valid state:

BlogCommenter commenter = new BlogCommenter("Chris", "Beams");
commenter.setMiddleInitial('S');

This reduces the likelihood of NullPoninterExceptions down the road, and specifies a clear contract to users of your class as to how it should be used. No guesswork as to which setters 'must' be called, etc. These benefits, IMHO, outweigh the decreased readability caused by the fact that constructor args do not have names in the spring configuration XML, particularly because classes may be used in contexts outside Spring configuration. In these cases, we want to rely on the language as much as possible to inform us about how to use the class. Constructors are the natural choice here.

Now, if only the p: namespace allowed for some syntactic sugar around constructor args
- Chris