Nel DOM, perché childNodes è definita nell'interfaccia Node se solo alcuni tipi di nodo come Element , Document e DocumentFragement , possono avere childNodes ?
Questo è considerato un buon design? In quali casi questo è ammissibile? Voglio dire, non è come definire un raggio su un'interfaccia Shape anche se sappiamo che non tutte le forme hanno un raggio?
Il semplice motivo per cui questo fa parte delle specifiche è che rende molto più facile attraversare un albero DOM. È sempre possibile eseguire iterazioni sui childNode di un nodo, anche se non ce ne sono. Altrimenti, dovresti determinare il tipo di nodo in ogni punto della traversa.
Il motivo per cui questo è corretto è che childNodes ha un valore logico e significativo per non elementi: una raccolta vuota . D'altra parte, nell'esempio radius, qualsiasi valore che potrebbe avere per le non ellissi è completamente privo di significato.
Chi dice che solo Element s può avere figli nodi? Ci sono un sacco di tipi di nodi, e molti di loro possono avere figli. Esempi ovvi includono Document e DocumentFragment , nessuno dei quali è Element s, ma entrambi hanno nodi figli.
Il Modello composito ha due varianti:
Ricorda che lo scopo del pattern composito è di trattare singoli oggetti e raccolte di tali elementi in modo uniforme . Data una struttura appropriata, i metodi compositi possono essere implementati in un modo che ha un significato anche sulle foglie. Per esempio. nel contesto del DOM, un nodo di testo non ha childs e può restituire un NodeList vuoto.
Questa seconda variante del pattern Composite non è sempre applicabile, ma in alcuni casi può aumentare l'eleganza del design (avrei comunque progettato il DOM senza questa stranezza).