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:

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).