CODEWITHSUNDEEP
javaxmlxml-parsing
israkir
israkir

Reputation: 2131

The functionality of Document in a parser implementation

Recently I was studying about parsers including the design patterns used to built one. The example I have chosen is javax.xml.parsers and org.w3c.dom packages.

Looks like factory and builder patterns used to design the parser structure in these packages. DocumentBuilderFactory is to return an immediate factory to build DocumentBuilder. DocumentBuilder, then, uses its parse() method to parse an xml file; but the return type is Document in this case: Document doc = builder.parse(in);

But, what I didn't get here is Document is an interface which contains plenty of methods to manipulate XML attributes. It also extends Node interface. We can still call its operations: doc.hasAttributes() or doc.getChildNodes() etc.

I spent an hour on this, but still couldn't get the logic behind this architecture:

1) Where are those Document's methods implemented?

2) Why is it better to return interface type object (Document) to represent the DOM object after parsing?

Upvotes: 1

Views: 109

Answers (2)

Andreas Dolk
Andreas Dolk

Reputation: 114787

Document, Node, Element and all of the other types are interfaces. There are a couple of libraries around that provide an implementation for those interfaces - one prominent example is Apache Xerces. From their front page:

Xerces2 also provides a complete implementation of the Document Object Model Level 3 Core and Load/Save W3C Recommendations and provides a complete implementation of the XML Inclusions (XInclude) W3C Recommendation.

If you exactly need to know which implementation of DOM is actually used, start a debugger or dump the class name of your Document object to the console/log.

Upvotes: 2

Istao
Istao

Reputation: 7585

You have, on the DocumentBuilderFactory javadoc, the policy to get the real class DocumentBuilderFactory, and all the rest, at public static DocumentBuilderFactory newInstance().

Upvotes: 0

Related Questions