Gary Gregory wrote:
How about this as a compromise (thinking aloud):
The (currently imaginary) class VariableFormat holds a Map and defines a
method VariableFormat#resolve(String name).
[configuration] can subclass the class and override the
VariableFormat#resolve(String name) to provide its own logic. This would
allow for the resolve by delegation scenario.
You would "normally" front-load a VariableFormat with a Map.
I'm in two minds about this.
This design is neat, and definitely fits the [lang] scope question (so
long as StrBuilder can use it directly without copying the char[])
However, it has to be said that if VariableResolver is the only
interface we are talking about, then it is little different to
StrTokenizer, so could be considered OK.
Maybe this is a sign that StrTokenizer is too complex? I do think that
we should have a consistent design between StrTokenizer and
VariableFormat though.
(could VariableFormat be called StrFormatter to fit with the rest of the
classes in the package?).
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
