Lessons Learned
Place as much logic as possible in element classes. |
XML and Java are good friends! |
Avoid circular dependencies:
they hint
a better design is around the corner. |
Keep classes small, and packages modular. |
Previous
Narrative
Put Logic in Element Classes
The xs, xu and da packages all implement their main functionality in
their specialised element classes. This has several benefits:
-
Extra functionality can be added by writing new element classes and registering
them. In the case of the XSL engine, once the infrastructure was in place,
implementing each of the XSL elements (eg. 'empty', 'eval') is solely a
matter of implementing element classes; no other part of the software is
affected. Thus extensions to XSL can be added cleanly and easily.
-
It's very easy to locate the code that is responsible for a particular
purpose.
-
Using 'put logic in element classes' as a guiding principal cuts the number
of design decisions a developer has to make. This ought to (!) lead to
fewer messy implementations.
-
The functionality outside the element classes is very small. Thus all
the classes tend to be small (though there may be lots of them).
Further start-up processing can be invoked as required, provided the element
classes required have been registered beforehand. Registering must currently
be hard-coded, although it would be straightforward to define an element
whose purpose is to register other elements and allow their use immediately.
The xt application uses'DatabaseDriver' elements to load JDBC driver classes
(although there appears to be a bug in the JDK - because they are not visible
after start-up, although manually loading them in exactly the same way
later does work).
XML and Java are Good Friends!
The dynamic nature of Java (primarily its ability to instantiate any
class solely from its name) means software can be called about which the
caller knows very little. This can be the basis of extremely expandable
applications. This ability can be harnessed to XML in at least two ways:
The xs, xu and df packages all implement their main functionality in
their specialised element classes. This has several benefits:
-
The classes used to handle different types of XML elements can be easily
changed (as we have seen). Special processing for particular elements can
be slotted in on the fly.
-
Class names can be placed in XML files, so new classes can be added without
changes to the calling application. (Parameters can be obtained from XML
files too.)
(There are security issues here, the solutions to which this margin is
too narrow to contain.)
Avoid Circular Dependencies
It was originally very difficult to find a design for the XSL engine
which avoided circular dependencies: rules contain actions, actions invoke
rules. But determination to avoid a circular dependency here prompted a
search for an alternative, which led to a neater solution: the introduction
of a 'stylist' class to drive the processing. (It should be noted that
the 'stylist' class is actually quite small and not complex.)
Keep Classes Small, and Packages
Modular
These are, rather, lessons from OO/Java experience than anything to
do with XML!