Conclusion: Types of XML 'Usage'
Classes
Common features of all of Steve's usages:
Manager (or Engine)
- for overall control |
Elements - where the real work is done,
containing all the important
application functionality: everything
else is just infrastructure
-
Allows functionality (types of elements)
to be added with no change to infrastructure
-
Makes code easy to find: it's easy
to see which class to look in
-
May be invisible to developer (eg.
user interface elements in xu)
|
Catalysts - critical
process control classes (eg. parser, stylist)
-
Mutual dependencies may indicate
that introducing a catalyst class will help
-
Classes typically small, but containing
important logic
|
Servants -
everything else (including customizers and
views) |
This is a highly modular approach, which is takes expansion
in its stride and results in smallish classes with clearly defined roles.
(It almost forces the developer to be well-behaved!)
|
# classes
|
Total .class size (kb)
|
% of .class size
|
xs - XSL engine |
|
(Average = 2.7)
|
|
Manager
|
1
|
4.5
|
9%
|
Elements
|
10
|
21.5
|
42%
|
Catalysts
|
1
|
7.0
|
14%
|
Servants
|
7
|
17.7
|
35%
|
xu - User interface |
|
(Average = 2.3)
|
|
Manager
|
1
|
6.3
|
11%
|
Elements
|
11
|
27.1
|
48%
|
Catalysts
|
0
|
0
|
0%
|
Servants
|
12
|
22.4
|
40%
|
da - Database
analysis |
|
(Average = 2.6)
|
|
Manager
|
1
|
1.1
|
3%
|
Elements
|
9
|
22.3
|
53%
|
Catalysts
|
0
|
0
|
0%
|
Servants
|
6
|
18.6
|
44%
|
Previous
Next
Narrative
Steve has identified common threads in the three XML 'usages' he has
so far developed, in terms of the roles of their classes. These threads
have been picked out of the structure the software at the end of its evolution
(if it has ended!), rather than being a design approach imposed from the
outset. They have thus been derived from experience, not because they sound
like a good idea. Using this approach, Steve sees classes as divided into
four types:
-
Manager (or Engine) class. This co-ordinates everything, and is
typically the starting point for usage's main activity. For example, in
xu, the FrameConfigManager class registers actions and then loads the configuration;
in xs, the XSL engine initiates the applying of an XSL stylesheet. The
manager is usually not a large or complex class - typically delegating
to other classes.
-
Element classes, where Steve recommends all the real application
functionality should live.rimarily to allow special PI parsers to be slotted
in.
-
Catalyst classes, for important control logic. These differ from
the Manager in that they are brought into being as and when necessary,
and usually have only a short life-span. Steve detests mutual dependencies
between classes, and catalyst classes can sometimes be used to avoid them.
(This is the origin of the XSL Stylist class.)
-
Servant classes, for everything else. This is a bit of a cop-out
from a classification point of view, but there appears to be little to
be gained from categorising things further in short notes such as these.
This approach builds upon the idea of the node type registry (previously
discussed), which is what permits new element classes to be introduced
at any time with no changes to any other software - irrespective
of the purpose of our particular usage. For example, xs allows new XSL
elements to be added - and because the main XSL functionality is implemented
in the element classes themselves, this facilitates easy extension of XSL
itself.
The table above breaks down each of the three existing 'usage' packages
into these four types of classes to show that, indeed, most of the code
is in the element classes. This is despite the 'servants' including a lot
of non-core classes in these cases: xu includes Swing look-and-feel classes
and a base frame; da includes its dialog box classes. xs is not a full
XSL implementation, but would be made so by the introduction of further
element classes but little else (so the element classes' percentage will
rise still further). Another aspect identified in the table is the small
average class size (2.3-2.7 kb per .class file).