DOM and inheritance

Mark Harwood wrote:
>For example, the OO developer using the "element" interface does not
>have access to a method to "getAttributes". For that, they are expected
>to use the "non-OO" base interface "Node".

In an OO environment, classes inherit methods from their superclasses.
Since the Element interface is a sub-interface of Node (": Node" in the
IDL), Elements have all the methods and IDL attributes that Nodes do, plus
those explicitly added in Element's definition.

Thus, getAttributes is implicitly defined to be part of an Element's API.
And that of any other class derived from Node, even though none of the
others will ever return anything but null when this method is called. The
result is just as if getAttributes was explicitly defined and implemented
on all those subclasses; it's just easier to describe and easier to
implement consistantly.

Note isn't only for non-OO developers. It's the anchor point for APIs (such
as this one) which are shared by all the subclasses of Node, and for
behaviors which are shared by most. That's OOP in a nutshell.

The fact that Node _also_ allows a flattened view is almost incidental. But
it's a valuable side-effect, and supporting that view is why the
getAttributes API was declared to exist on all nodes even though only
Element will respond usefully to it.


"Look at Chicolini! He sits there alone, an abject figure."
"I abject!"
"... I say, Look at Chicolini! He sits there alone, a pitiable object --
let's see you turn _that_ into a straight line!"
     -- Groucho and Chico Marx, inaccurately quoted.
______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.

Received on Friday, 25 September 1998 12:23:10 UTC