+1
Why use string-based binding like that in Java, among whose main
strengths is rigorous type safety?
Sometimes in frameworks you'll do that, e.g., name an implementing class
in a properties or XML configuration file, but the cost is always
deferral of less-expensive compile-time safety to later, more costly
run-time type failures. The benefit had better be worth it, and also
worth the fragmentation of logic across more source artifacts.
I've seen the sacrifice made in code, too. That's just an execration.
One egregious example I saw used reflection and casting to obtain a
no-argument constructor based on matching class names to certain other
class names, but still requiring casting through those same types. They
sacrificed type safety, performance, simplicity and good sense to create
a "factory" that had none of the benefits of an actual factory.
Prefer compile-time type assertions to run-time matchups.
I agree with you guys in general, but I'm not sure I see the problem for
the situation we are discussing. Whether it's FXML or Facelets XHTML in
JSF, or XAML over in .NET land [1], you're talking about things that
have strong mappings to the code-behind (whether Java or C#).
There is no need to discover only at _runtime_ that your "strings" were
wrong. Both JSF Facelets XHTML and FXML are amenable to having a great
deal of rigorous checking done by hypothetical toolsets before the
underlying Java ever gets compiled. If a particular method in a
particular Java class is called for, that can be checked in principle
before building.
If your hypothetical tool is "screwing you" every time you make a typo
or other mistake when moving, renaming or otherwise refactoring things,
then I suggest that the hypothetical tool sucks...to use technical
terminology. As an example, let's say I've got EL in a JSF Facelets page
that references a couple of managed beans. So you've got references to
the @ManagedBean or @Named names, to the getters/setters in those
classes, and to action methods. You're seriously telling me that a
decent tool couldn't solidly track the reference bindings and do proper
refactorings for that stuff?
Same goes for FXML: where elements of FXML are references to Java
things, a proper tool can clearly maintain the mappings between FXML and
Java.
Surprise, surprise: you actually do have some tools out there that
competently do stuff like this, like IntelliJ IDEA for JSF 2.0.
And you know, you can thoroughly mess up when renaming, moving or
otherwise refactoring in a pure Java environment too, and all your
compiler will tell you is in how many places you now have a mistake.
I've seen plenty of cases where developers - myself included - thought
they knew all the usage sites of something, and figured to manually
refactor. In more than just a few cases that manual refactoring resulted
in something that *compiled* just fine, but was now erroneous, maybe
because you typo'd something. It can absolutely happen, easily actually.
So using *tool*-assisted refactoring makes much sense. In which case,
why is one kind of tool-assisted management OK and another kind bad?
AHS
1. XAML not the same thing as the other technologies I mention, but in
one of its uses, as a UI markup language in WPF, there are strong
similarities.