Quale potrebbe essere un buon modello di progettazione per calcoli numerici complessi tra tre o più modelli di dati diversi?

Beh, non credo che ci sia un modello di progettazione che può aiutarti, ma forse qualche "tattica". Onestamente, è difficile darti una buona risposta con così poche informazioni. Ecco i miei pensieri, sulla base di alcune ipotesi su come potrebbe essere il tuo codice:

• inizia rifattorizzando quel (troppo) grande metodo in metodi più piccoli. Rendi trasparente la struttura, inserisci le variabili per i risultati intermedi, disaccoppia le parti indipendenti del calcolo, assicurati che lo stesso calcolo non esista ridondante in due punti del codice sorgente. Inoltre, presenta le strutture dati per gli attributi che appartengono insieme

• visualizza il flusso di dati (ad esempio, disegnando un diagramma del flusso di dati). Questo ti aiuterà a capire meglio le dipendenze e probabilmente ti aiuterà a rifare ulteriormente in parti o componenti indipendenti. Ti aiuterà anche a capire dove devi cambiare qualcosa quando si presenta una nuova esigenza.

• controlla se hai veramente bisogno di un "modello push" per i tuoi calcoli (una modifica in un attributo innesca una sequenza di calcoli, devi aggiornare molte variabili intermedie, forse avere a che fare con effetti collaterali indesiderati) oppure se è possibile passare a un "pull model" più funzionale (solo quando è necessario un valore specifico vengono avviati i calcoli correlati, calcolando tutti i risultati intermedi dallo stato corrente delle variabili di input). Un "modello di pull" funziona come una vista SQL in un DB relazionale, un "modello push" come una tabella di utilità in un database relazionale che deve essere riempito con dati ridondanti.

• potrebbe essere anche una buona idea disaccoppiare il tuo programma da "3 diversi modelli di dati" introducendo un livello intermedio che fornisce al tuo codice di calcolo una visualizzazione dei dati che è adatta alle sue esigenze. Ma con così poche informazioni su come potrebbe essere il tuo calcolo, non sono sicuro che questa sia la decisione giusta nel tuo caso, devi decidere tu stesso.

Bene, qualcosa che potrebbe essere utile per te sta facendo Refactor:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring. http://refactoring.com/

C'è un libro a riguardo.

In ogni caso. Ero nella stessa situazione e devo fare un sacco di refactoring, come:

Semplificazione dei blocchi di istruzioni if nei metodi che eseguono "Decompose Conditional"

Decompose Conditional Hai una dichiarazione condizionale complicata (if-then-else). Estrai metodi dalla condizione, poi dalla parte e da altre parti.

if (date.before (SUMMER_START) | | date.after( SUMMER_END))
     charge = quantity * _winterRate + _winterServiceCharge; 
else    
     charge = quantity * _summerRate; 

Modificato per:

if (notSummer( date))
    charge = winterCharge( quantity);
else
    charge = summerCharge (quantity);

Consolidamento di espressioni condizionali in un unico metodo. Ad esempio, se ho un gruppo di if in un metodo prima di fare il vero lavoro, allora raggruppo tutti i if in un solo metodo

Una volta che hai fatto un refactoring del tuo codice, ti rendi conto che è facile spostare i pastic insieme quindi a quel punto suggerirei il modello Strategy.

In computer programming, the strategy pattern (also known as the policy pattern) is a software design pattern, whereby an algorithm's behaviour can be selected at runtime. http://en.wikipedia.org/wiki/Strategy_pattern

e, infine, rimuovere le istruzioni switch (se ce l'hai) con un po 'di polimorismo.