Molti algoritmi utilizzati nell'informatica scientifica hanno una struttura intrinseca diversa rispetto agli algoritmi comunemente considerati nelle forme meno ingegneristiche di ingegneria del software. In particolare, i singoli algoritmi matematici tendono ad essere altamente complessi, spesso coinvolgono centinaia o migliaia di righe di codice, tuttavia non coinvolgono alcuno stato (cioè non agiscono su una struttura di dati complessa) e possono spesso essere ridotti in termini programmatici interfaccia - a una singola funzione che agisce su un array (o due).
Ciò suggerisce che una funzione, e non una classe, è l'interfaccia naturale per la maggior parte degli algoritmi riscontrati nell'informatica scientifica. Tuttavia, questa argomentazione offre poche informazioni su come gestire l'implementazione di algoritmi complessi e multiparte.
Mentre l'approccio tradizionale è stato semplicemente quello di avere una funzione che chiama un numero di altre funzioni, passando gli argomenti pertinenti lungo la strada, OOP offre un approccio diverso, in cui gli algoritmi possono essere incapsulati come classi. Per chiarezza, incapsulando un algoritmo in una classe, intendo creare una classe in cui gli input dell'algoritmo vengono immessi nel costruttore della classe e quindi viene chiamato un metodo pubblico per richiamare effettivamente l'algoritmo. Una simile implementazione di multigrid in psuedocode C ++ potrebbe apparire come:
class multigrid {
private:
x_, b_
[grid structure]
restrict(...)
interpolate(...)
relax(...)
public:
multigrid(x,b) : x_(x), b_(b) { }
run()
}
multigrid::run() {
[call restrict, interpolate, relax, etc.]
}
La mia domanda è quindi la seguente: quali sono i vantaggi e gli svantaggi di questo tipo di pratica rispetto a un approccio più tradizionale senza lezioni? Ci sono problemi di estensibilità o manutenibilità? Per essere chiari, non ho intenzione di sollecitare l'opinione, ma piuttosto di comprendere meglio gli effetti a valle (cioè quelli che potrebbero non sorgere fino a quando una base di codice non diventerà abbastanza grande) dell'adozione di tale pratica di codifica.