Sto scrivendo una libreria per calcoli di algebra lineare sparsa come back-end per il mio lavoro di tesi e sono arrivato a un po 'di un bivio. Sto usando il moderno Fortran (non gemere, ha ereditato e polimorfismo e tutto il jazz per 10 anni).
Da un punto di vista del design del software, il mio problema principale consisteva nel far sì che i risolutori iterativi fossero in grado di utilizzare matrici sparse senza sapere in quale formato di archiviazione si trovassero. L'unica funzionalità di cui un risolutore iterativo deve sapere è come moltiplicare una matrice per un vettore.
L'ho fatto avendo una classe astratta sparse_matrix con un metodo virtuale matvec per la moltiplicazione di matrice-vettore; poi c'erano diverse classi figlio, che rappresentano ogni formato di archiviazione, che sovrascrivevano il matvec padre con la loro implementazione. Credo che questo sia chiamato il modello "modello" sì?
Sto prendendo in considerazione il refactoring del mio codice per usare la composizione sull'ereditarietà. A tal fine, una matrice sparsa consiste in un grafico sottostante con alcuni dati extra - a volte è una matrice di numeri reali o complessi, a volte una matrice di matrici dense, ecc. Esistono più formati di matrice sparse che utilizzano lo stesso grafico sottostante schema di archiviazione. Ogni matrice sparsa ha un oggetto graph come attributo e ha una collezione di puntatori di funzione che cambiano per usare quel grafico in modi diversi. Prima, dovevo ridefinire efficacemente lo stesso schema di archiviazione del grafico per ogni formato di matrice sparsa che lo usava.
I vantaggi che posso distinguere sono:
- meno classi rendono più semplice l'aggancio del mio codice a C / C ++ / Python
- facile scegliere diverse implementazioni parallele dello stesso algoritmo; scrivere ogni implementazione e reindirizzare i puntatori di funzione in fase di runtime. Prima dovevo usare grandi blocchi condizionali.
- Penso che questo disegno sarà più facile quando il grafico sottostante è meglio pensato come un iper-grafico, e le matrici come composizioni eterogenee di diverse matrici in formati possibilmente diversi. (Questo accade in alcune applicazioni PDE.)
Qualcuno può pensare a una buona ragione per cui dovrei attenermi al vecchio progetto basato sull'eredità? Se il nuovo approccio è più ragionevole, qualsiasi consiglio oltre a quello che viene detto in GoF sarebbe apprezzato.