Lists Home |
Date Index |
** Reply to message from Jeff Lowery <email@example.com> on Tue, 29 Oct
2002 10:25:39 -0800
> > Sure, and I've seen enormous problems come out of people
> > "compiling" XML schemas into classes using the tools that are now available.
> > I mean, one of the main reasons for using XML is to decouple applications, and
> > then people compile the XML schemas into code so that they tightly couple their
> > applications to this week's version of the XML.
> How about instead of generating classes, these code generators generated
> interfaces + implementations? Still not perfect, but at least you're coding
> your app to an interface. You can then change the interface, either through
> extension or dynamic proxies. The implementation classes can also be
> extended, or rewritten altogether if needs be.
No, no help at all. It's not a problem that you solve by trying to use another
Java feature. The problem is if the auto-generated XML->Java code is called
from all throughout the application codebase. If the XML changes, everything
breaks. You need to hide the auto-generated code behind a facade so that almost
all of the application code is unable to call it directly. Then, when there are
changes to the XML, the effect on the codebase is limited to a small,
pre-determined set of classes.
Anthony B. Coates, Information & Software Architect
MDDL Editor (Market Data Definition Language)