Un modo per osservare questo è che ogni volta che si dispone di una struttura dati che fa riferimento a un'altra struttura dati, si ha una qualche forma di oggetto grafico. A quel livello, qualsiasi linguaggio orientato agli oggetti supporta un grafico. Alcune lingue non sono orientate agli oggetti e utilizzano invece una mappa per archiviare strutture dati correlate. Questo crea anche grafici di mappe correlate, quindi qualsiasi lingua con un array associativo (PHP) o hashMap (Clojure, perl, ecc.) Può creare grafici con mappe.
Ma penso che tu stia chiedendo perché non ci sono più prese che hanno qualcosa di simile
Node {
Iterator<Node> getAdjacentNodes();
}
Graph {
void putNode(Node n);
Iterator<Node> getAllNodes();
}
Guarda Datomic. Anche i negozi tripli usano qualcosa di simile. Allo stesso modo, le tabelle di riferimento incrociato (xrif) nei database relazionali possono essere utilizzate per creare grafici arbitrari delle relazioni.
Detto questo, potrei riaffermare la tua domanda come "Perché non più linguaggi di programmazione e kit di strumenti adottano un approccio basato su grafici per la decomposizione dei problemi?"
Penso che la risposta sia che il traversal grafico generico efficiente è un problema NP-Hard privo di un modo universale ed efficiente per elaborare i grafici e anche un modo universale ed efficiente per dimostrare che una singola soluzione è la più efficiente (es. il problema del commesso viaggiatore).
I grafi sono assolutamente essenziali per ogni studente di CS da imparare perché si occupano delle relazioni più generali tra i dati. Eppure per la stessa ragione, dovrebbero essere la tua ultima scelta su come rappresentare le relazioni. La maggior parte delle relazioni sono più specifiche. Un'auto dovrebbe avere un solo guidatore e una posizione su una determinata strada alla volta. Generalmente non vi è alcun motivo per unire tutte le auto con tutti i possibili conducenti e tutte le possibili strade. Fare così inviterà problemi inutilmente difficili. Più sono specifici i rapporti tra gli oggetti o le funzioni nella progettazione del programma, più è possibile ottimizzare tali relazioni e più è facile comprenderle e testarle.
Infine, come attraversi i grafici? C'è profondità prima e larghezza. La maggior parte dei linguaggi di programmazione facilita l'attraversamento della larghezza:
select * from passenger where car_id = 3;
myCar.getCurrentPassengers();
Quando guardi la ricerca in profondità, non esiste un modo giusto per farlo. Qual è la strada migliore da New York a San Francisco? È risolvibile, ma solo con un approccio abbastanza brutale. Se le intersezioni sono nodi e le strade sono spigoli, ciò non aiuta a risolvere questo problema. Molto meglio è sapere qualcosa sulle strade - quali sono interstatali, hanno semafori o segnali di stop, sono in costruzione, sono inclini al traffico, sono chiusi o non sono ancora stati costruiti? La ricerca del tuo percorso da New York a San Francisco potrebbe iniziare con solo interstatali, quindi esaminare gli angoli di intersezione in cui cambi le strade o la distanza massima da una linea retta (bene, curva intorno al globo). Questi sono punti fermi per trovare una soluzione ottimale in modo efficiente. Accennano ai luoghi per verificare la presenza di altre strade locali che funzionano attorno a una soluzione interstatale tutt'altro che ideale. I dettagli del problema sono esattamente ciò che rende possibile trovare il percorso in tempo reale, nel mondo reale. Tuttavia, i dettagli sono esattamente l'aspetto del traversamento grafico che un'API generica non catturerebbe.
Potrebbero esserci metodi myNode.setWeight(double d) e myNode.getWeight() , ma non definiscono ancora un ordine di iterazione in un modo migliore di quello che hai appena aggiunto una voce weight al tuo campo hashMap o weight sul tuo oggetto. Inoltre, potrebbero esserci pesi diversi per le piste ciclabili o il trasporto pubblico, o qualsiasi altra cosa. Avresti un set o un hash di pesi per ogni nodo? Immagino di non vedere l'uso di una struttura dati grafica generica perché solo gli aspetti non generici dei tuoi dati possono rendere un grafico percorribile in qualsiasi cosa vicina al tempo polinomiale.