Prev: Best Java Collection Book
Next: POI Excel Sheet String Formats
From: Simon Brooke on 12 Jul 2010 03:54
On Sun, 11 Jul 2010 10:44:17 +0200, Robert Klemme wrote:

> From the point of modularity I would definitively refactor the creation
> code out into a separate method - even if it's just a private one. This
> helps keep your other method much more readable.

Fair point. Indeed, as I do exactly similar things with other types of
pluggable modules, it might be better to have a method

public <T> instantiateAndConfigure<T>( String configToken,
Context config)

> Btw, what's the value of "authenticator" if the config does not contain
> this entry? Is there some default value?

Defaults to JDBCAuthenticator, because in the general case I authenticate
against first class database users (actual database user accounts); but I
can plug in authenticators which authenticate against a particular
database table or against OpenId, for example.

> In that case I'd structure
> the code rather as
>
> final String authClassName = config.getValueAsString(
> AUTHENTICATORCLASSMAGICTOKEN);
> authenticator = authClassName == null ? createDefaultAuth() :
> createAuth(authClassName);
> authenticator.init( config );
>
> If this is in the constructor you can even make "authenticator" final
> (if it is supposed to never change of course).

Again, good point, thanks. It's not (typically) in a constructor because
most of my stuff extends Servlets where the constructor does not have
access to the configuration; but it is typically in the init() method so
it's pretty much the same thing.

--

;; Semper in faecibus sumus, sole profundam variat

 | 
Pages: 1
Prev: Best Java Collection Book
Next: POI Excel Sheet String Formats