Come progettare un'applicazione algoritmica, pesante e a luce di oggetti

7

A parte i vertici, i bordi, le facce e le mesh, il mio progetto / applicazione di elaborazione della geometria ha solo una mezza dozzina di altre entità come le curve sulle superfici. Tuttavia la maggior parte del mio codice è dedicata all'elaborazione della geometria. Essendo un programmatore ingenuo quando ho iniziato questo progetto, ho implementato i vari algoritmi di elaborazione della geometria come metodi delle poche classi che avevo. Di conseguenza, alcune delle mie classi ora sono molto grandi perché implementano algoritmi di elaborazione della geometria (e quindi estendono fino a 5 * file .cpp) - molto male. In alcuni casi ho anche implementato gli algoritmi come classi nei loro diritti. Come tale, ora ho classi che non sono realmente entità. Ora ho un problema con questo perché ora credo che le classi dovrebbero essere entità instanziabili e i loro metodi le cose che fanno. Tuttavia, seguire questa regola ha portato a file di grandi dimensioni. Allo stesso tempo deviare da esso ha portato a classi che non hanno senso come entità istantanee, ad es. una classe geodetica.

Comunque sto pianificando una riprogettazione di questo progetto e mi farebbe piacere consigliarti su come degnare le mie lezioni. Una delle opzioni che ho considerato è quella di implementare ogni algoritmo come una raccolta di metodi in uno spazio dei nomi. Tuttavia, poiché gli spazi dei nomi non hanno variabili di istanza, ci sarà un sacco di argomenti che passano tra i metodi - ancora non molto bello.

    
posta Olumide 12.08.2011 - 13:41
fonte

2 risposte

10

Trovo che anche con problemi incentrati sull'algoritmo, puoi ancora trovare modi per separare le responsabilità in classi separate. Potresti essere un po 'troppo rigido nel pensare a cosa dovrebbe essere un oggetto. Se avessi un algoritmo potrei avere classi come FooCalculator e BarAccumulator e MyAlgorithmOrchestrator. Per quanto mi riguarda, quelle sono "entità istantanee" perfettamente valide. Solo perché potrebbero non avere senso come oggetti fisici non significa che non abbiano senso come oggetti algoritmici.

    
risposta data 12.08.2011 - 13:47
fonte
5

As a result, some of my classes are now very large because they implement geometry processing algorithms (and therefore span up to 5 *.cpp files)

Se è C ++, hai la possibilità di implementare direttamente funzioni indipendenti come bevel , extrude , decimate , subdivide , ecc.

    
risposta data 29.01.2018 - 23:44
fonte

Leggi altre domande sui tag