La fonctionnalité de Document dans une implémentation d'analyseur

Question

Récemment, j'ai étudié les analyseurs, y compris les modèles de conception utilisés pour en construire un. L'exemple que j'ai choisi est javax.xml.parsers et les paquets org.w3c.dom.

Ressemble aux modèles d'usine et de construction utilisés pour concevoir la structure de l'analyseur dans ces packages. DocumentBuilderFactory doit renvoyer une fabrique immédiate pour générer DocumentBuilder. DocumentBuilder, puis, utilise sa méthode parse() pour analyser un fichier xml; mais le type de retour est Document dans ce cas: Document doc = builder.parse(in);

Mais, ce que je n'ai pas compris ici, Document est une interface qui contient beaucoup de méthodes pour manipuler les attributs XML. Il étend également l'interface Node. Nous pouvons encore appeler ses opérations: doc.hasAttributes() ou doc.getChildNodes() etc.

J'ai passé une heure à ce sujet, mais ne pouvait toujours pas la logique derrière cette architecture:

1) Où sont les méthodes de ces documents mis en œuvre?

2) Pourquoi vaut-il mieux retourner un objet de type interface (Document) pour représenter l'objet DOM après l'analyse?

Answer 1

Document, Node, Element et tous les autres types sont des interfaces. Il y a quelques bibliothèques autour qui fournissent une implémentation pour ces interfaces - un exemple important est Apache Xerces. A partir de leur page d'accueil:

Xerces2 fournit également une implémentation complète du modèle objet de document niveau 3 de base et recommandations de charge/Save W3C et fournit une implémentation complète des Inclusions XML (XInclude) Recommandation du W3C.

Si vous avez besoin de savoir exactement qui la mise en œuvre des DOM est effectivement utilisé, lancer un débogueur ou vider le nom de classe de votre objet Document à la console/log.

Answer 2

Vous avez, sur le DocumentBuilderFactory javadoc, la politique pour obtenir le DocumentBuilderFactory de classe réelle, et tout le reste, à public static DocumentBuilderFactory newInstance().